I did notice the @handle.invalid! Thanks!
I did notice the @handle.invalid! Thanks!
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.
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.
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.
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.
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.
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!