The AT protocol is the most obtuse crock of shit • Hacker News Board

Re: The AT protocol is the most obtuse crock of shit

#491

Post by cynix » Mon, May 15, 2023, 7:37 PM UTC

teddyfrozevelt wrote: post #416

pfraze wrote: post #54

Okay well. I work on Bluesky and helped build the AT Protocol. I'm sorry Sam differs with us on this, and I'm glad that Activity Pub is already there for him. However, Sam doesn't understand the ATProto very well and I want to clear it up a bit. Before I do, let me just say: Bluesky and the AT Proto are in beta. The stuff that seems incomplete or poorly documented is incomplete and poorly documented. Everything has m…

Not to derail this thread, but is there any way of seeing whether I'm actually on the waitlist? I remember signing up late last year, but there was never any confirmation and I never got the survey which I've heard people talking about. I'm super interested to try out Bluesky, but haven't been able to find anyone with an invite.

Also would like to know this, I haven’t received any confirmation email or survey either, and each time I “join the waitlist” it just gives me a success message as if I’m not already on the list.

Re: The AT protocol is the most obtuse crock of shit

#492

Post by Ferkv » Tue, May 16, 2023, 10:58 AM UTC

account42 wrote: post #471

Ferkv wrote: post #462

Earlier quoted context omitted.

User Identity in ATProto is decentralized, it's meant to use W3C DIDs. That's actually one of the things that bugs me about ActivityPub... unless I'm running my own one-single-user instance I won't have control over my own identity. It's also very weird how even on a supposedly "federated" system the only way to ensure you can access content from all instances (even if they differ in philosophy or are on opposite sid…

I agree that the siloing happening with AP instances is not a good thing and it's the main reason I have not bothered with the fediverse. But this isn't a technological limitation with the protocol at all but a policy chosen by the operators. What makes you think that this won't apply to BlueSky or other ATProto instances (when they allow federation at all)?

If the protocol is designed in such a way that it allows the operators of one instance to have full control over what some user identities can access to in the whole network, then it's an issue in the protocol. Imho, the problem is likely inherent to the way the AP fediverse commonly defines "federation".

I'd rather favor a more decentralized structure that allows the users to directly access content from any content provider that hosts it through the protocol (ie. without necessarily requiring another specific instance to index that content from their side.. if they index it great, but if they don't it should still be possible to access it using the same user account from a different index), with a common protocol that allows a separation between identity management and content provider.

From what I understood, ATProto is closer to that concept.

Re: The AT protocol is the most obtuse crock of shit

#493

Post by Ferkv » Tue, May 16, 2023, 11:45 AM UTC

lucideer wrote: post #490

Ferkv wrote: post #462

Earlier quoted context omitted.

User Identity in ATProto is decentralized, it's meant to use W3C DIDs. That's actually one of the things that bugs me about ActivityPub... unless I'm running my own one-single-user instance I won't have control over my own identity. It's also very weird how even on a supposedly "federated" system the only way to ensure you can access content from all instances (even if they differ in philosophy or are on opposite sid…

> User Identity in ATProto is decentralized It is but that's largely conceptual so doesn't really mean anything in the context of the protocol. These are message exchange protocols so the defining element is whether the messaging is federated or decentralised. Fwiw AP also supports DID I just haven't seen any implementations use it, since it strongly recommends other ID (a mistake imo). > It's also very weird how...…

> most instances allow individual users to follow individual users on another "blocked" instance - its usually just promotion/sharing & discovery that are restricted.

If they are still allowing access to all forms of third party content through their own instance (even if they restrict the discoverability) then they are still risking being held responsible for that content. So imho, that would be a mistake.

Personally, if I were to host my own instance under such a protocol, I'd rather NOT allow any potentially illegal content that might come from an instance I don't trust to be distributed/hosted by my node.

The problem, imho, is in the way the content needs to be cached/proxied through the node of the user in order for the user to be able to consume it. This is an issue in the design of how federation typically works.

I'd rather favor a more decentralized approach that uses standards to ensure a user identity can carry over across different nodes of content providers, whether those nodes directly federate among themselves or not.

There should be a separation between identity providers and content providers, in such a way that identity providers have freedom to access different content providers, and content providers can take care of moderation without necessarily having to worry about content from other content providers with maybe different moderation standards.

I'm not saying ATProto is that solution... but it seems to me it's a step in the right direction, since they separate the "Personal Data Server" from the "Big Graph Services" that index the content. I can host my own personal single-user server without having all the baggage of federating all the content I want to consume. The protocol is better suited for that use case.

In services using ActivityPub, instances are designed for hosting communities, they come with baggage that's overkill for a single-user service but that's still mandated due to how the communications work, they expect each instance to do its own indexing/discovery/proxying. So they are bound to be heavier and more troublesome to self-host, and at the same time, from what I've seen, the cross-instance mechanisms for aggregation in services like Mastodon are lacking.