macgenie
https://micro.blog/macgenie
•
permalink
@aaronpk Let's plan on meeting next Wednesday, and we'll figure out a good place by then. I think Homebrew and Microblog are an excellent fit, and I would be honored to co-host!
gerwitz
https://micro.blog/gerwitz
•
permalink
@aaronpk first thought: “Gah! That’s my provider!”
Second thought: “Wait, do I login with OpenID anywhere?”
macgenie
https://micro.blog/macgenie
•
permalink
@aaronpk Let's plan on meeting next Wednesday, and we'll figure out a good place by then. I think Homebrew and Microblog are an excellent fit, and I would be honored to co-host!
macgenie
https://micro.blog/macgenie
•
permalink
@aaronpk I haven't been to Rogue with a group, but it could work. Maybe we should try that. How many Homebrewers would you expect. I think the Microbloggers will be a small contingent to start. @verso: thoughts?
macgenie
https://micro.blog/macgenie
•
permalink
@aaronpk @verso and I were trying to come up with the equivalent of the Green Dragon, since we are calling it Microblog and Microbrew! I like Lucky Lab, but it is admittedly noisy and the food options are meh.
macgenie
https://micro.blog/macgenie
•
permalink
@aaronpk That's a great idea! Do you want to meet up next Wednesday?
Aaron Parecki
https://aaronparecki.com/
•
Mar 7
Aperture consumes the u-photo property on posts. All 3 current Microsub clients (Monocle, Together, and Indigenous) also consume the property to display photos in the reader interfaces.
manton
https://micro.blog/manton
•
permalink
@jeremycherfas I wonder if any other kind of bridge is possible for the IndieWebCamp channels. I connect via Slack and it seems like several other people do as well.
jameysharp
https://github.com/jameysharp
•
Mar 6
I'm writing an essay on what technology is missing for decentralized publishing of serial content (webcomics, fanfiction, podcasts, etc) and read-state synchronization is one of my topics. I'm hoping Microsub can be one good answer in that context.
For the kinds of serials that have ongoing plot/continuity, it's worth noting that
As a result, individual entry read-marks matter here because you'd like to know that there's something new even though it comes before entries you've already read.
Also: old entries can be edited. You may want to know that you read an older version of the entry so you can decide whether you care to read the updates, so I'd like to keep track of what the last-modified timestamp was for the version of the entry that you read. Note that this is not the same as the timestamp when you read the entry, because you might be racing with the publisher's updates.
I could picture it also being useful to record the timestamp when you read each entry for some kind of data analysis later—for example, predicting which feeds you like best, or clustering feeds that you like to read in close proximity to each other. But I don't think that's important for a first version of this spec.
Interesting use case!
I feel like it's worth pointing out that the spec only needs to describe as much as is required for interop between clients and servers, and servers are free to do as many additional fancy things as they want.
I could picture it also being useful to record the timestamp when you read each entry for some kind of data analysis later
Sounds like it might not hurt to also have the client send a timestamp of when the item was marked read, in case the client is syncing a bunch of these read-marks after being offline. Of course servers are free to ignore that if they don't support tracking the timestamp of reads.
creators sometimes add or remove entries arbitrarily far back in the archive
Issue #24 could help in this case, being able to retrieve only the unread items in a timeline.
