WeChat ID
aaronpk_tv
-
jsorge
https://micro.blog/jsorge
•
permalink
@aaronpk @brentsimmons Thank you! Why would anyone put more than one feed on a page?
I don't think they do, but gotta cover all the cases when you're writing code! -
Here's the current recommendation: https://indieweb.org/h-feed#multiple_h-feeds_in_the_same_page
tl;dr: use only the first h-feed unless there is a fragment identifier on the second
fwiw I haven't actually encountered this case in the wild yet when I was writing all my h-feed consuming code -
at StreamPDXPortland, Oregon • Tue, February 13, 2018 5:48pm
-
grantcodes
https://github.com/grantcodes
•
Feb 13
Working on implementing this in together now, I'm sure there is a valid reason, but I'm just wondering why the
_idis different from the paging before and after values, could they not be the same?
The
beforeandaftervalues are meant to represent pages of data, not necessarily individual records. In my case, theaftervalue refers to an item that isn't in the current page. I could return a string for_idthat looks more like thebeforeandafterstrings, but that's just an implementation detail of my server. Alternately I may switch mybefore/afterstrings to look more like the current_idvalue. Either way, this difference doesn't seem important to the client. -
That would be an interesting feature that the microsub server could provide to clients. It does seem like this will always be a problem.
-
Bluetooth controlled Bescor MP-101 Pan Tilt Head modification - Mobile Modding (mobilemodding.info)
-
AsleepAwake7h 33mSlept11mAwake for
-
Channel icons?
I just added emoji in the channel names, and now I'm wondering if there should be a way to choose/upload an actual custom icon for channels.continue reading... -
Aaron Parecki
https://aaronparecki.com/
•
Feb 12
I'm implementing a draft of this in Aperture right now. Here is the current API...
I should add that the `_id` values are meant to be an identifier for this instance of the entry in the channel, not an identifier for the entry across channels. This means if you're following the same feed in multiple channels, entries may have a different `_id`. -
EdwardHinkle
https://github.com/EdwardHinkle
•
Feb 12
Not that it has to be implemented right now, but I do want to make a case for the “updated” field of a channel. In order to reduce “high noise signal”, for most of my channels, I’ll want the channel’s “unread indicator” to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying “there are new posts here” rather than saying “there are unread posts here”. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and haven’t read, while only being prompted to open the channel if there are new posts. The “new posts” indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I haven’t read (which is why this can’t just use the “last_read_entry”, even though that is a useful method).
(Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)
Here's a question. Do you imagine this additional state being something that only individual clients are aware of, or should that be synced to the server as well?
If the server returns the "updated" date, then the client has enough information to show the indicator itself. But as far as other clients are concerned, they wouldn't know about whether you've seen those posts in another client.
I'm kind of leaning towards it being a client-only thing, at least for now.
If that's going to end up getting pushed to the server then I think we need to better define the different kinds of states. Maybe "read" vs "seen", where "seen" is the soft indicator that the client has displayed the post to the user, and "read" means they've opened it up (or maybe even explicitly marked it as read). -
Add option to remove entries when unfollowing a source
When removing a source from a channel, Aperture provides an option in the UI to either remove all the existing entries or just stop adding new entries. It may be useful for this to be an option for Microsub clients as well.continue reading... -
EdwardHinkle
https://github.com/EdwardHinkle
•
Feb 12
Not that it has to be implemented right now, but I do want to make a case for the “updated” field of a channel. In order to reduce “high noise signal”, for most of my channels, I’ll want the channel’s “unread indicator” to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying “there are new posts here” rather than saying “there are unread posts here”. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and haven’t read, while only being prompted to open the channel if there are new posts. The “new posts” indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I haven’t read (which is why this can’t just use the “last_read_entry”, even though that is a useful method).
(Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)
Now that you mention it, I think Facebook's notifications work this way.
They show a little number over the notification icon with the number of new notifications. However, they also track whether you've clicked on individual notifications separately. If you click the icon with the number, then the number is cleared and won't show again until there is new content. If you click on an individual notification, then the next time you drop down the notification bar that notification will be white instead of blue. -
With the work in tracking read state, I've started implementing these additional properties by prefixing them with
_. I felt like that was the least obtrusive way to include them while also making it obvious they are not part of the post vocabulary.Additional brainstorming around other per-item data should be discussed in new issues.
-
The
unreadproperty has been documented in the spec, and implemented in Aperture.I am not sure the
updatedproperty is useful, so I'm leaving it out for now. I'm going to close this issue as most of the discussion is taking place in #4.
