Bluesky now exceeds 13 million users, the AT Protocol developer ecosystem continues to grow, and we’ve shipped highly requested features like direct messages and video.
Alternative Title: “Bluesky pretty sure these leopards won’t eat their face.”
From what I understand, bsky’s architecture seems to allow federation at multiple levels. On one side the individual profiles are actually websites and the app aggregates the content almost as an RSS reader. I do see some profiles which are independent like Jeff Gierling’s, so yes federation at the profile level seems to work.
And this is really important because it is one way to prevent your data from being hostage by the service. Then there is another level of federation. I’m not entirely sure of the terminology here, but there is one aggregator aspect, which is quite compute intensive. And that one I don’t know if there is another instance of it. But functionally speaking, I’m quite impressed by the technical aspect of bsky. There has been a lot of thought put into it.
And monetizing it is not the issue, the problem is mostly how. That they have some paid features is fine, it’s even important that there are ways to monetize it without milking their users of their privacy.
Let’s hope this works out and becomes sustainable while respecting the users!
The aggregator is called the Relay, and I haven’t even found anything suggesting one could realistically selfhost it. Then you need to handle the massive stream of data coming through it with AppViews, which are tough to handle too (there are a few but not many iirc).
That said, I am also impressed with the thought behind ATProtocol. It seems much more robust and defined than ActivityPub.
That link doesn’t work for me, but I ended up finding a post by them that seems to correspond. Good to know, thanks! Seems like it’s realistic but expensive still (150$/mo?), and it’s not gonna get cheaper… I hope they figure out a way to make them less centralized.
That’s probably because they built a protocol specifically for a usecase, rather than building a protocol and hoping that someone will come along with a usecase.
My understanding was that activitypub was basically a rough formalization of existing protocols, designed to be as flexible as possible. More a template than a real protocol. Unfortunately mastodon’s popularity basically made a bunch of things de-facto obligatory but not well documented, and there’s still a bunch of ways to do… anything.
Bluesky’s federation model is actually quite interesting, they go for a very portable approach vs activitypub’s instance-basis. Unfortunately, there’s still a massive centralization point (the main relay, the only thing that can really handle the firehose), and identity is also centralized, albeit has mechanisms to be decentralized.
I believe that’s your handle, not your identity. Your handle resolves to your identity, but your identity isn’t directly tied to it, in case you lose the domain.
While they definitely do this for handles I’m pretty confident this is also done for DIDs (Decentralized identifiers) and it doesn’t provide a solution if you lose your domain. I think Bluesky (Appview) specifically gets around this by also tying your DID:web to your DID:plc, in case of domain loss. So I think it exists on the protocol but they don’t automatically utilize the decentralization for end-user experience(domain loss) but other appviews can. But I could be wrong.
Yeah, did:web exists, but I still called it centralized because it still relies on did:plc pretty much everywhere (though honestly domain name handles might actually be did:web, not sure). Didn’t know about that dual setup by Bluesky though!
saw this comin a mile away. does it count as federation if you only federate with yourself?
From what I understand, bsky’s architecture seems to allow federation at multiple levels. On one side the individual profiles are actually websites and the app aggregates the content almost as an RSS reader. I do see some profiles which are independent like Jeff Gierling’s, so yes federation at the profile level seems to work.
And this is really important because it is one way to prevent your data from being hostage by the service. Then there is another level of federation. I’m not entirely sure of the terminology here, but there is one aggregator aspect, which is quite compute intensive. And that one I don’t know if there is another instance of it. But functionally speaking, I’m quite impressed by the technical aspect of bsky. There has been a lot of thought put into it.
And monetizing it is not the issue, the problem is mostly how. That they have some paid features is fine, it’s even important that there are ways to monetize it without milking their users of their privacy.
Let’s hope this works out and becomes sustainable while respecting the users!
The aggregator is called the Relay, and I haven’t even found anything suggesting one could realistically selfhost it. Then you need to handle the massive stream of data coming through it with AppViews, which are tough to handle too (there are a few but not many iirc).
That said, I am also impressed with the thought behind ATProtocol. It seems much more robust and defined than ActivityPub.
Check this out, this person self-hosted one for fun
That link doesn’t work for me, but I ended up finding a post by them that seems to correspond. Good to know, thanks! Seems like it’s realistic but expensive still (150$/mo?), and it’s not gonna get cheaper… I hope they figure out a way to make them less centralized.
Ah sorry, bad timing, the handle stopped working a few hours ago, maybe the person has changed it, here is the same link with the handle-agnostic DID in the url: https://bsky.app/profile/did:plc:by3jhwdqgbtrcc7q4tkkv3cf/post/3l47yhps2xv2c
I did notice the @handle.invalid! Thanks!
I wanted to check it out, but the post appears to be deleted?
Ah sorry, bad timing, the handle stopped working a few hours ago, maybe the person has changed it, here is the same link with the handle-agnostic DID in the url: https://bsky.app/profile/did:plc:by3jhwdqgbtrcc7q4tkkv3cf/post/3l47yhps2xv2c
That’s probably because they built a protocol specifically for a usecase, rather than building a protocol and hoping that someone will come along with a usecase.
My understanding was that activitypub was basically a rough formalization of existing protocols, designed to be as flexible as possible. More a template than a real protocol. Unfortunately mastodon’s popularity basically made a bunch of things de-facto obligatory but not well documented, and there’s still a bunch of ways to do… anything.
FTFA: “Launched federation for self-hosters and developers. Now there are over 1,000 other personal data servers (PDS) outside of Bluesky.”
Bluesky’s federation model is actually quite interesting, they go for a very portable approach vs activitypub’s instance-basis. Unfortunately, there’s still a massive centralization point (the main relay, the only thing that can really handle the firehose), and identity is also centralized, albeit has mechanisms to be decentralized.
Aren’t identities already decentralized by using domains you own as your identity? Ex. Incase you’re unfamiliar, my Bluesky @ is my domain I own.
I believe that’s your handle, not your identity. Your handle resolves to your identity, but your identity isn’t directly tied to it, in case you lose the domain.
While they definitely do this for handles I’m pretty confident this is also done for DIDs (Decentralized identifiers) and it doesn’t provide a solution if you lose your domain. I think Bluesky (Appview) specifically gets around this by also tying your DID:web to your DID:plc, in case of domain loss. So I think it exists on the protocol but they don’t automatically utilize the decentralization for end-user experience(domain loss) but other appviews can. But I could be wrong.
https://atproto.com/specs/did
Yeah, did:web exists, but I still called it centralized because it still relies on did:plc pretty much everywhere (though honestly domain name handles might actually be did:web, not sure). Didn’t know about that dual setup by Bluesky though!
Yes? Obviously it’s way less than ideal but it’s still federation
Depends on whose graph you’re looking at