For blog posts, I'd look to RSS instead. That's where that content is traditionally published. Instead of SELECTing from bluesky's index, you can use OPML subscription lists. There are a bunch of places that curate feed lists, so it's significantly less likely to face API death like twitter did.
I run another variant which collects OPML blogrolls via crawling, so you can find out who else likes your favorite blog and what else they recommend. Here's the page for Simon Willison's blog (https://blogroll-network.alexsci.com/discover/feed-a34ee2a88...). Thinking of RSS and blogrolls as a network feels much more resilient than blueskys Jetstream api endpoint.
> Thinking of RSS and blogrolls as a network feels much more resilient than blueskys Jetstream api endpoint.
Nothing to do with Bluesky services. There are many independent firehoses and relays. Here's a stream of standard.site blog posts coming in over a firehose hosted in Chennai. Every single one. No curator between me and the posts, and no work by me to crawl the whole network for them. https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fchennai.fir...
Edit: ok there is an aggregator, the relay is scraping all of the PDSs out there to build the event stream. Notably this is not possible with RSS, where you need to build a large index with knowledge. PDSs request relays to crawl and that's that.
I can't decide if ATProto is actually amazing or if its proponents are just dazzled by their own tech. Is it truly decentralized? What makes it better than Mastodon or Matrix or Scuttlebutt? Of course, at the end of the day, it's the network effects that matter. Attention is all you need indeed.
I will say that I have no relation to bluesky so it's not my tech and I do find it amazing. This post from Dan Abramov might help in clarifying how 'decentralized' it is compared to the threadiverse https://overreacted.io/there-are-no-instances-in-atproto/
The team came from the IPFS and Scuttlebutt worlds. "Better" is relative to your design goals. Iroh is better for point-to-point connections & localfirst. Matrix is better for chat rooms. Etc. The general logic of atproto was to serve large scale publishing with an open model that doesn't seriously degrade the UX. The scale orientation means - at least until the non-public spaces land - you're syncing a lot of records to provide an alternative microblogger to bluesky. The account hosting system, however - the pds - remains exceedingly cheap and easy to run. Pros and cons, matching with the design goals.
The Twitter-competitive social site is moribund, so I think maybe what you're seeing more and more of is the pivot towards infrastructure --- always planned, but not before such a big part of the messaging.
There are invariably 3 solutions to all “federated” web problems:
- Email
- Semantic HTML
- Web indexing services
In this case, it's mostly indexing and a little of the other two if you want to add social features. I despite ATProto with all my soul for taking a problem with such a simple and standard solution and totally obscuring it behind hundreds of layers of JSON, faux federated services, and technical jargon, all in service of creating an inferior version of Twitter. I guess it wouldn't be as sexy to offer a web indexing service instead.
For blog posts, I'd look to RSS instead. That's where that content is traditionally published. Instead of SELECTing from bluesky's index, you can use OPML subscription lists. There are a bunch of places that curate feed lists, so it's significantly less likely to face API death like twitter did.
There are multiple sites that support follower semantics over RSS. Feedland tracks subscriptions publicly, so you can see the blogs I read (https://feedland.com/?username=robalexdev), and who reads my blog (https://feedland.com/?feedurl=https%3A%2F%2Falexsci.com%2Fbl...).
I run another variant which collects OPML blogrolls via crawling, so you can find out who else likes your favorite blog and what else they recommend. Here's the page for Simon Willison's blog (https://blogroll-network.alexsci.com/discover/feed-a34ee2a88...). Thinking of RSS and blogrolls as a network feels much more resilient than blueskys Jetstream api endpoint.
> Thinking of RSS and blogrolls as a network feels much more resilient than blueskys Jetstream api endpoint.
Nothing to do with Bluesky services. There are many independent firehoses and relays. Here's a stream of standard.site blog posts coming in over a firehose hosted in Chennai. Every single one. No curator between me and the posts, and no work by me to crawl the whole network for them. https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fchennai.fir...
Edit: ok there is an aggregator, the relay is scraping all of the PDSs out there to build the event stream. Notably this is not possible with RSS, where you need to build a large index with knowledge. PDSs request relays to crawl and that's that.
>Simple: the network won. The developers stopped being an asset, and the API progressively closed.
You can add Reddit to that list, IPO is coming so better price out the third party apps we encouraged developers to build.
I can't decide if ATProto is actually amazing or if its proponents are just dazzled by their own tech. Is it truly decentralized? What makes it better than Mastodon or Matrix or Scuttlebutt? Of course, at the end of the day, it's the network effects that matter. Attention is all you need indeed.
I will say that I have no relation to bluesky so it's not my tech and I do find it amazing. This post from Dan Abramov might help in clarifying how 'decentralized' it is compared to the threadiverse https://overreacted.io/there-are-no-instances-in-atproto/
The team came from the IPFS and Scuttlebutt worlds. "Better" is relative to your design goals. Iroh is better for point-to-point connections & localfirst. Matrix is better for chat rooms. Etc. The general logic of atproto was to serve large scale publishing with an open model that doesn't seriously degrade the UX. The scale orientation means - at least until the non-public spaces land - you're syncing a lot of records to provide an alternative microblogger to bluesky. The account hosting system, however - the pds - remains exceedingly cheap and easy to run. Pros and cons, matching with the design goals.
The Twitter-competitive social site is moribund, so I think maybe what you're seeing more and more of is the pivot towards infrastructure --- always planned, but not before such a big part of the messaging.
There are invariably 3 solutions to all “federated” web problems:
- Email
- Semantic HTML
- Web indexing services
In this case, it's mostly indexing and a little of the other two if you want to add social features. I despite ATProto with all my soul for taking a problem with such a simple and standard solution and totally obscuring it behind hundreds of layers of JSON, faux federated services, and technical jargon, all in service of creating an inferior version of Twitter. I guess it wouldn't be as sexy to offer a web indexing service instead.