Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The AT Protocol

atproto.com

Post reply on HN
Print view View original

41–50 of 109 posts

Re: The AT Protocol

#43

Post by sneak »

gargron wrote: post #34
sneak wrote: post #28

Earlier quoted context omitted.

ActivityPub isn’t a great protocol and ties your identity to your homeserver.

ActivityPub, the protocol, doesn't actually tie your identity to your homeserver. Webfinger (which is the protocol responsible for the username@domain addresses) is not part of it. In fact, even Webfinger doesn't actually "tie" your identity to your homeserver -- the fact that your identity is "tied" is an implementation detail in Mastodon and other currently popular fediverse software.

That’s a de-facto standard, so it’s safe to say that, given that all major AP implementations do so, your identity is tied to your homeserver.

The tyranny of the installed base is real. What you choose to ship basically defines what everyone else can do with AP in practice.

I think it’s a shame that Mastodon got a million fuzzy blinky UI features before the (still missing) BYOdomain support, given that everyone in that space links permanent identity to user+domain.

I don’t see that changing. Do you? It seems everyone has settled on this, just like email, and that the solution is to just use a domain that you control for your identity (just like email).

Re: The AT Protocol

#44

Post by jonhohle »

I’ve not gotten fully through the spec, but why does the server hold the client’s signing key? That puts a lot of responsibility on a PDS that could be handled by the client, doesn’t it? If the client has their complete repo anyway, why can’t the PDS verify changes with a public key?

If it’s to aggregate likes, comments, etc., why not use a mailbox encrypted with the public key for unmerged data and allow the DID to decide whether or not to accept the content, aggregate it, and publish the updated repo? Other clients could choose whether or not to considered the merged mailbox when displaying to users (for example, likes could update automatically, but only accepted comments)

Re: The AT Protocol

#46

Post by Karrot_Kream »

skyfaller wrote: post #14

Can anyone explain why Bluesky is making a new protocol instead of using ActivityPub like Mastodon? What advantages would it have over ActivityPub? https://activitypub.rocks/ Worth noting that ActivityPub is an official W3C recommended standard. Is it just Not Invented Here syndrome? This could lead to https://xkcd.com/927/

ActivityPub's PublicInbox is used to route all messages. This works for "small-world networking" where you're in a tight-knit community exchanging messages with known or friend-of-friend actors, but doesn't work well for "big-world networking" with folks you don't know and don't necessarily want to share all or even most of your messages with (a pretty big pain point right now in the Fediverse.)

ATProtocol claims to differentiate between these cases by introducing the concept of indexers which can apply different algorithms to order feeds, but it's unclear to me how exactly that will work.

Re: The AT Protocol

#47

Post by dchnshA »

Nah thanks, I'll stick with ActivityPub.

The fact they even felt the need to create another protocol instead of using, improving and contributing to ActivityPub makes me think they want to bake a busines modell for themselves into the technology and they can't do that if they don't have full control over the spec.

ActivityPub is organically grown from a community to serve that community. Bluesky is created to combine making the profits of a commercial centralized social network + profiting from the investment from crypto bros.

ActivityPub is not perfect and nobody is pretending like it is (there is a big blog post from the co-author about what retrospectively they should have done differently, sadly I couldn't find the link), but a specification is not static ! If you have a suggestion to improve it you can propose changes and a lot of things are left to the implementation, so you can just do things differently than other ActivityPub application currently do.

In fact there are people building the future of the ActivityPub ecosystem right now: https://spritely.institute/

There is no need to create yet another specification. The only feature this claims to have, that all ActivityPub implementations currently don't have is identity portability and that can actually be implemented without changes to the ActivityPub spec, just no ActivityPub Application has implemented it yet.

Re: The AT Protocol

#48

Post by pfraze »

jonhohle wrote: post #44

I’ve not gotten fully through the spec, but why does the server hold the client’s signing key? That puts a lot of responsibility on a PDS that could be handled by the client, doesn’t it? If the client has their complete repo anyway, why can’t the PDS verify changes with a public key? If it’s to aggregate likes, comments, etc., why not use a mailbox encrypted with the public key for unmerged data and allow the DID to…

Basically -- to keep it simple. Holding the signing key in the PDS simplifies linearization and reduces device-pairing actions.

We spent most of the summer planning to store the signing key in the user device(s) but during a late design session we examined why exactly we wanted that, and realized the main reason was for account portability^1. Thing is, we dont need the primary signing key to be local for account portability; we just need a recovery key that allows the user to assign control away from the PDS later. So we switched to a server-held signing key, but we kept in the architectural pieces that make client-held signing keys possible, in case we want to explore that again in the future.

^1 We're interested in end-to-end encryption but that's not what the signing key would accomplish and will need to be developed later. Hopefully we haven't painted ourselves into a corner for that part of things.

Post reply on HN