> I want this to work, furthermore, whether those people are sharing a random thought every day, a blog post every week, or an art project every two years.
> More importantly, every board holds its place, regardless of when it was last updated.
I would not like to stare at the same board for two years between updates, so probably I would end up manually re-organizing my client according to the feeds that get updated, or just unsubscribe from the ones where the author seems to have dropped off the planet.
Newspaper classifieds and comic book ads are different each issue and therefore there's some pleasure in scanning through them. Today's algorithmic feeds on social networks may optimize too much for engagement at the expense of quality. (Twitter started putting complete strangers' tweets at the top of my timeline, on topics like "Marvel" that I have no interest in.) But the solution to this is not to avoid algorithmic curation completely.
* if posts are limited to 2217 bytes with no external references then that excludes the richness of images, something I really enjoy about the modern web. Am I misunderstanding something?
* I think there's a pile of room for the client to display things differently from that imagined here. ultimately we would end up with clients that implement their own "algorithm", but that's a good thing because we're in charge of it.
* I always get irrationally stressed about the inefficiency of pinging a server every hour for a resource that only gets modified once a year, one of the use cases noted in the article. That's a lot of wasted 304 not-modified's.
I love the idea of just seeing everyone's current status, but realistically I want to be able to read people's history as well, otherwise the FOMO will have me checking this thing manually every minute (maybe an effective growth hack, but sounds like it'd end up even worse than twitter if it worked at all).
And realistically an RSS reader with a "tile view" achieves everything that this does.
As ever, the issue will be achieving the critical mass needed for the network effect to kick in. But the system is simple enough to have a chance at succeeding (see Gall's Law)
Also, I'm not sure how important having the month and year in the identifier is to the whole thing, but using only two digits for the year has obvious ambiguities.
That the client must "situate each board inside its own Shadow DOM" seems to imply that all clients must effectively be web browsers too. A far cry from the original RFC 865 which could basically be done with netcat.
All in all this seems like a complex way to solve a seemingly easy problem.
Still can, I'm thinking.
Without an easy way to pay for content online, this will be subject to the same distorting, ad-infiltrating forces as the web in general. Charging even tiny fees for content online resolves a host of problems... while of course creating others.
But I think the basic idea is fine.
