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.
My current thought for this is to add a new property to the entry with the source's h-card info:
{
"type": "entry",
"url": "https://example.com/1000",
...
...
"_source": {
"url": https://example.com/",
"name": "Example Feed",
"photo": "https://example.com/photo.jpg"
}
}
My main question is whether the url should be the home page URL of the feed or the actual feed URL. I'm almost thinking we need to be able to include both.
If you're following an Atom/RSS/JSONfeed, then the feed URL is not something you'd want to send a user to, so you'd want the "home page" URL instead. For HTML feeds, it would be fine to use the feed URL directly.
However from a security perspective, if the entry's URL is on a different domain than the URL the entry was found on, the UI may want to indicate this in some way, similar to how my webmentions display the source URL as "via ____" if the source URL domain is different from the entry's reported URL. The main case this might happen is an aggregator where the every item in the feed is from a different domain than the aggregator's feed. Also micro.blog feeds where the post's original URL is reported instead of the micro.blog URL.
So I'm thinking we might need two properties, feed URL and home page URL. Unfortunately this no longer maps well to h-card. Any ideas?
The majority of the use of this gem is for sending webmentions from sites that use h-entry, since it's expected that the receiver will go parse the page and find the h-entry on the sending site. Without the filter of only finding links inside the h-entry, this gem would end up sending a bunch of webmentions to pages such as links in navigation or the site footer, which is usually not the desired result.
