Live data from Hacker News

The AT Protocol

atproto.com

71–80 of 109 posts

Re: The AT Protocol

#71

This seems really cool. I have looked at ActivityPub quite a bit and written a little basic client/server but the identity portability thing is pretty much a nonstarter for it to be taken seriously in normal circles. I’ve found the content quality of the fediverse to be abysmally low thus far, I think AT could work especially because of the big name behind it. Twitter did the Ruby community a huge solid back in the d…

Most fediverse users were banned from Twitter or quit Twitter for ideological reasons.

That first clause is an exceptional claim. I don’t know anyone in the fediverse who’s there because they can’t be on Twitter. I do know plenty of people who left because it was becoming a raging cesspit of algorithm-driving extremism.

Re: The AT Protocol

#72
post #36

Bluesky is Twitter's right? Will be cool if they come away with something actually decentralized. Trial in beta with hackers, then one day, in-place swap Twitter to run on it. Pipe dream?

While Bluesky PBLLC received initial funding from Twitter Inc, Twitter (whether under its current management or impending Musk ownership) has no ownership interest or veto-power over the Bluesky plans.

Though Agrawal seemed interested enough that Bluesky would potentially have had an 'inside track' to getting Twitter to interoperate, Twitter's proprietary platform interests may have always made that tricky. Under new management, anything could happen.

Re: The AT Protocol

#73

Oh they mean 'At'-protocol. I was thinking Hayes 'AT' commands.

Which still lives on today in cellular networks. At least up to LTE, I haven't looked lately to see if they're sticking around for 5G. https://www.rfwireless-world.com/Terminology/modem-AT-comman...

If you are talking to one of those self-contained, postage stamp-sized GSM modules using a microcontroller, chances are there'll be a serial link to it, and it's listening to Hayes commands.

Re: The AT Protocol

#74
Hmm I don't get it.

What's the point? Social network software falls into 1) real software you use already with a dedicated circle of people who care 2) people who don't care and just use one of the relatively 'poor' common networks (e.g. twitter, FB).

Who is this marketed at?

Reading the comments it seems others are struggling to see the point - the existing communities are mostly served even if the software is not great. There's not enough value-add.

Came here expecting to read about an interesting protocol not a social network protocol without an app...

Re: The AT Protocol

#75

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…

This is not right. First of all, what do you mean by "PublicInbox"? Are you referring to the optional sharedInbox attribute, which allows delivering a payload to a whole server at once instead of iterating over the personal inbox of every actor on the server? Or are you referring to the inbox in general? The inbox is just a mechanism to deliver a payload from point A to point B. It is in fact used to receive messages from folks you don't know, but there is no obligation to share all or even most of your messages with anyone in particular. You can deliver posts to your followers, but you don't have to, protocol-wise, and you can choose, person by person, who to deliver to. The concept of indexers doesn't seem foreign to ActivityPub either. PeerTube runs sepia.search, which is exactly that kind of indexer that powers search for their video platform.

Re: The AT Protocol

#76
post #57

I don’t think I have time for a full review, but making $ext a map seems short sighted. In the example, a poll is included, great. What if you want two polls? It’s another level of indirection, but making $ext a list (unless the encoding protocol handles multiple values with the same key). This also allows for a specified ordering of extensions, provided that makes sense.

We're open to that possibility. We know the broad idea we want to apply with schema extensions, but we're still figuring out the right DX on the execution.

You're about to reinvent JSON-LD.

Re: The AT Protocol

#77
post #43
post #34

Earlier quoted context omitted.

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 th…

"Fuzzy blinky UI features" is what people actually care about though. You can have all the theoretical bells and whistles in the protocol but if you don't have a flagship application that people can use for their everyday needs, nobody is going to care. The fact of the matter is that "porting your account" is just a much less frequent need than literally anything else that people will come across in their day to day use, and the fact that you can move to another account in the fediverse without losing your followers is good enough for most. Of course it would be nice if the old and new accounts were verbatim, not even identifiably different copies, but we're talking about synchronizing (potentially, and likely on average) multiple gigabytes of data across small hobbyist servers that also still have to serve requests from other users. Not to mention the abuseability of being able to import gigabytes of pre-recorded content like that, a spammer's boon. Worth mentioning that the account portability approach described in ATP is just "upload your backup to the other server" which in practice is going to suffer from the exact problems I am describing.

Re: The AT Protocol

#78
post #33

Earlier quoted context omitted.

How would you ever handle deleting posts or removing content if there's a Merkle tree that gets invalidated for every deleted post you send?

The root gets updated with each update, and the diff gets exchanged as part of the sync protocol. Deleting and purging is no different than other federated protocols in that regard.

Rewriting the user's entire database on each delete sounds like it might become a problem. Especially as some users like to automatically delete old posts on a regular basis.

Re: The AT Protocol

#79
post #47

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…

'The specification may be terrible, and everything good about it may be implementation-specific, and every touted feature you're looking for may be missing from the only implementations anyone uses, but you can always just break compatibility from all the de facto standards, and so that's no reason to come up with your own base standard' seems flatly wrong, and that actually is a pretty great reason to come up with y…

The choices aren't "just break compatibility with all de facto standards" and "come up with your own base standard". You can work on an extension to the protocol that everyone can adopt and move to if it's really an improvement.

Re: The AT Protocol

#80

Earlier quoted context omitted.

Yeah.. when I saw that and something about joining a waitlist for something that should be developed in public I noped my way out. I hope other people learn have similar BS indicators and don't fall for this stuff. There is nothing open about joining a wait-list.

It’s a waitlist for the first app, not the protocol itself.

Wouldn't it be better to simply have a notification for the newsletter to keep people informed about the community work and where and how they can contribute. The page is full of content suggesting that users are simply to wait back while this supposedly open protocol is developed with no community involvement.
Post reply on HN