WeChat ID
aaronpk_tv
Tuesday, March 6, 2018
-
-
This was amazing. @chadwickboseman surprises #BlackPanther fans while they say what the movie means to them.
-
@apulianas if you like using spreadsheets for monthly finances, you might benefit from my Mac app, Cashculator. It’s a smart spreadsheet for finances. Maybe it’ll fit your financial workflow. If you do, let me know what you think of its approach.
-
My current thought for this is to add a new property to the entry with the source's
h-cardinfo:{ "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
urlshould 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? -
Improve reply contexts
Improve reply contexts by inspecting the reply URL, as documented on https://indieweb.org/reply-context#Minimal_text_reply_contextscontinue reading... -
Provide an option to return only unread entries in a timeline
By default, a call to retrieve the timeline will still return already-read entries. However, in certain cases, such as if there are lots of unread entries and you start reading them from newest to oldest, or if somehow an entry was added far back in the timeline, you might want to see only the unread items.continue reading... -
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
- entry order matters, and
- creators sometimes add or remove entries arbitrarily far back in the archive.
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.
-
