ATProto Webfinger query response - Following, liking, reposting

[SlashScreen]

I know you guys are probably sick of hearing about ActivityPub, and I understand it's a hot-button issue. However, I understand what ATProto does differently than Pub and why it does things the way it does. I believe both protocols can co-exist, though.

It is pretty obvious by the way both protocols are laid out that they are fundamentally incompatible, like with transferring users, etc. But my question is, what would it take for ATProto to at least allow for basic functions so that users can interact? Liking, Following, Reposting.

I understand this isn't the highest priority right now. I am just curious as to why at least the basic functions cannot have a basic level of interoperability. I've done a fair bit of research into making my own bridger that allows for easy interop between the two systems without direct involvement from bsky or mastodon, but I have determined it impossible. However, implementing something rudementary directly in the server could be possible, at least form my point of view.

The basic idea from what I see could be something like servers adding a route to handle webfinger pokes, and return reformatted ATProto data in response. As for the other way, I'm not 100% sure yet.

I am absolutely not afraid to put my money where my mouth is and get my hands dirty here, but I want to know if there's a larger reason this cannot be done that I was missing. Other than political reasons, of course.

[snarfed]

I've done a fair bit of research into making my own bridger that allows for easy interop between the two systems without direct involvement from bsky or mastodon, but I have determined it impossible.

Interesting! I'm curious why you think it's impossible? I'm most of the way toward having this bridge built: https://snarfed.org/2023-09-09_bridgy-fed-status-update-5 , https://fed.brid.gy/docs#translate . (I've been bridging related protocols for over a decade: https://fed.brid.gy/ and https://brid.gy/ .) Have you discovered some showstopper for bridging ATProto specifically?

On a related note, if you're interested in all this, I'd love to work together!

[snarfed]

As to why the team isn't doing this themselves, they've said before (informally) that 1) they believe translating between different protocols is usually brittle, loses fidelity, and generally provides a somewhat degraded user experience, and 2) they have a ton of work to do just building the current protocol and implementation, so adding extra protocols isn't a top priority. Both points make sense to me. They're supportive of community bridge efforts though!

[bnewbold]

I'm personally quite interested in keeping up with ActivityPub and allowing interoperation when it makes sense.

A large potential area of concern is policy and "social contract" concerns about violating user consent and expectations. atproto content is generally world-public and enumerable/indexable, while activitypub is not, and folks there have (legitimate) concerns about their data and metadata being harvested and redistributed.

A specific initial technical friction to resolve is how to reference identities in an interoperable way. If you have any proposals around that I would be curious!

[snarfed]

A specific initial technical friction to resolve is how to reference identities in an interoperable way. If you have any proposals around that I would be curious!

@bnewbold here's a very rough first draft, feedback is welcome! https://fed.brid.gy/docs#translate

[SlashScreen]

re: @snarfed

• I should have clarified - a bridge is possible, but I meant more of a service that exists independently of both parties (i.e. not having to add an ATProto bridge to your mastodon instance) that acts as a proxy for both sides, and works for both networks as a whole.
• I totally get the jankiness that comes with supporting different formats and whatnot, I've been there myself. A lot of planning needs to go into that kind of thing to make it not feel decidedly 2nd class. The best I can come up with at the top of my head is something like a basic IR that can translate to and from the two data protocols, at least for the scope of basic interaction, like your bridger. This way, instead of writing a bunch of extra code and else statements to account for possible ActivityPub input, it's first fed through a transpiler of sorts. Of course, that could be how none of this works, and I am misunderstanding how these things work.

re: @bnewbold

• I see, so ATProto's info is publicly accessible/scrapeable, while apub's is not. I can see why that would make the more privacy focused uncomfortable. However, I don't see how, say, @[email protected] reposting @[email protected]'s toot would expose Bob to a web spider. Unless, I realize as I'm typing this out, if the ATProto API enabled fetching resources from the otherwise-locked mastodon system, at least for that one post. That, I'm not sure how to solve at the moment.
• The resource thing is tricky indeed. How much of an identity needs to be known, though? ATProto appears to use these DIDs, and allows for two different methods/formats of them. What's preventing a 3rd format that encodes/directly uses APub's ID (which from what I can tell is just a hyperlink)? Well, I guess then it wouldn't be DID-only, and maybe that would be encroaching on the ATProto spec, where instead we probably want to avoid having APub seep into ATProto's core. That's legacy code waiting to happen.

[snarfed]

the content needs to be available to everyone (which apub isn't always)

Fediverse (ActivityPub) data tends to be more publicly accessible than most people think. As long as you sign an HTTP request with a fediverse user's key - any fediverse user - you can fetch pretty much any object activity from any server, apart from DMs and followers-only posts. Many fediverse servers may block certain instances and web crawlers in robots.txt, but neither of those is actual access control.

I'm not entirely sure how the DID Document resolution works

DID docs are stored and served separately from DIDs themselves. did:plc resolution docs: https://github.com/bluesky-social/did-method-plc#did-resolution , did:web: https://w3c-ccg.github.io/did-method-web/#read-resolve

[SlashScreen]

@bnewbold Is there something every ATProto validator has in common? Credentials, etc. Is the validator the ATProto host server?

[bnewbold]

I'm not sure exactly what you mean by "ATProto validator", but i'll take a guess:

Validation of identities and public repo data in atproto can be done by anybody with no extra state or secrets, using open source code. Identities, including both DIDs and handles, can be resolved using standard web tech (DNS and HTTP/S), and did:plc specifically can be verified by fetching an audit log and verifying the public key signatures in the chain. All of the data is "self-certifying" and there is no external root-of-trust, other than the usual HTTPS certificate authorities for any HTTPS requests. Not everything about the identity system is self-certifying: eg, DNS responses and HTTPS /.well-known/ responses have the usual authority/security properties (and holes) when using those protocols.

Creating or changing identities and data does require credentials.

The current architecture is to rely on the PDS instance for a lot. Clients don't have to locally re-validate anything, they can trust their PDS instance to do the public identity resolution and validation for the. The PDS might also be lazy and delegate that trust onwards if it trusts other services. The PDS does (in the current model) hold on to private keys and do signing/updates on behalf of the client.

Not sure if this answered your question.

[SlashScreen]

@bnewbold Okay, I may have misunderstood. What does Validating ATProto data mean in this context, who does it, and why?
PDS means an instance of an ATProto service, right?

[snarfed]

PDS means an instance of an ATProto service, right?

Yes. https://atproto.com/guides/applications

What does Validating ATProto data mean in this context, who does it, and why?

Here, @bnewbold described resolving (loading) DIDs and domain handles and checking that they match: https://atproto.com/guides/identity , https://atproto.com/specs/did , https://atproto.com/specs/handle

There are other forms too, eg validating data against lexicon schemas, https://atproto.com/guides/lexicon , and verifying signatures, https://atproto.com/specs/repository#commit-objects .

[SlashScreen]

@SlashScreen as a proof of concept, try searching for @[email protected] in any fediverse server you're logged into

Oh yeah, this is how I imagined it would work. It seems to work for other people I want to follow too, although it takes a little bit of time. Did this just go live? It doesn't have old posts.

[SlashScreen]

oh, and sometimes name validation errors happen...

[snarfed]

It's definitely not complete or fully functional yet. Only profiles are exposed right now, just one way, not posts or following or other interactions. Those will have to wait until the Bluesky team turns on federation in prod.

[SlashScreen]

I'm glad to see that some ATProto members also see the value in cross-communication, even if ATProto doesn't seem to be there yet.

[erlend-sh]

Continued here: #1716