My view on this is... sure why not? The devil is in the details, but the actual code in @robin 's post is a valid as2 actor as far as I can tell. The 'over ATProto' part seems superfluous. From the perspective of an ActivityPub client, it's 'just' an ActivityPub Server + feature detection. It's not clear why the 'over' is necessary, or why it would be 'ActivityPub over ATProto' and not 'ATProto over ActivityPub'. But maybe just better to avoid the preposition altogether.
@robin @volkris Now I'm even more confused. Like I said, the devil is in the details, and it might be impossible to justify the 'over' preposition in any direction without showing a little bit more about what you expect to be sent over the wire...
The proposal is an interesting idea, but I think if you write down what's sent over the wire, it'll be clear that either 1) it's not ActivityPub at all (so it's not AP over ATP) and/or 2) it is AP aka HTTP (over ?), but the ATP is superfluous
@robin @volkris cool we both want that. ATP isn't needed for those (not saying it can't be shoehorned in).
Using DID URIs with ActivityPub, which is already allowed by the protocol, is what makes it possible. `did:plc` is one very opionated DID method, but imho there's no reason to constrain to it. End-users and implementation operators are in the best position to pick their supported did method, not protocol designers.
Protocol designers can design for the did-method-agnostic DID abstraction.
@bengo @volkris How do you get credible exit for AP?
I'm not saying that PLC is ideal (it's temporary) but being opinionated is important. Open-ended everything just leads to the same kind of adoption profile that semweb stuff has (and XML had): a super-committed core and no one else understands what it's for. It might be good to learn from experience there.
@robin It could be useful to formalize what you mean by 'credible exit', e.g. maybe we could add to https://www.w3.org/wiki/Socialig/Use_Case_TF
Let's say you mean something like what Gordon describes here. https://subconscious.substack.com/p/credible-exit
It says it in there: DNS is a pretty good start. Regardless of social protocol, you can get some kind of credible exit by letting end-users bring their own identifier to the social service provider. Mastodon doesn't do that.
But it should be considered best practice to have your ActivityPub Actor ID use a different domain from your inbox provider. https://bengo.is/actor.json
@robin I also found this which perhaps I should read :P https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty
@bengo @robin say what you will about bluesky's BYOID approach, i LOVE that they partnered with namecheap to make a dead-simple, commodity DNS-based solution. i would love it if AP adopted something flexible enough to accomodate people BYO-ing the identifiers they bought through namecheap/BS (i haven't really thought through the details if whether that would work only for migration or only for duplicate/multiple accounts)
@by_caballero @bengo Much agreed. I don't want to focus on that because it's not specifically a protocol feature, but it's great product work enabled by the protocol. And there's nothing about that indirection that couldn't work for AP too.
@bengo @robin Every ActivityPub actor uses an URL for identity. It would be nice if more servers implemented Bring Your Own Domain for accounts; I only know of Takahē for now. As the social web grows, lwe're all going to have more identities, like with email: one from your university, one from each of your employers, one or two from your ISPs or other service providers, one you register and maintain carefully for yourself and your household.
@evan @bengo @robin one of my strongly-held-beliefs is that the "protocols don't matter"; I think the realpolitik of RCS-SMS-iMessage(lol)-WhatsApp-Signal supports this. All use a common identity, and could/would be made "interoperable" with the stroke of a single law by a single large nation state/federation. aka Postel was right.
The one thing that makes me sad is that ATP (and Matrix) have chosen different identifiers, which makes interop a human problem vs. a tech one. 😢
@evan @bengo @robin that said, I think there's a reasonable chance that if people started putting ATP links in their webfinger profiles or AP urls in their ATP profiles, the two are effectively equivalent and interoperable. Doing so, and/or having multiple feeds-per-profile could have quite an impact in terms of opening up the space for playing with interop. I'm a little surprised it hasn't been done more (maybe I just haven't seen it?).
@robin @evan @bengo yes! I'd personally love to see what having multiple feeds would look like in today's specworld. The original intent of webfinger profiles (which became xrd? I stopped following aeons ago) was to have multiple type/rel values, so you'd have e.g. rel="photos", rel="blog", rel="newsletter", rel="tweets", rel="snark"/type="atproto" (sub appropriate content type/url/whathaveyou), etc.
@blaine @robin @evan What i like about ActivityPub Actor IDs and did:web, but not as easy in webfinger and what I understand of atproto, is that in the former the 'role identifiers' are just URL subpaths, and in the latter the domain name operator can gatekeep them.
Yes domain names for identifiers are cool. But URLs are even cooler.
e.g.
did:web:bengo.is -> https://bengo.is/.well-known/did.json
did:web:bengo.is:work -> https://bengo.is/work/did.json
did:web:bengo.is:work:jokes -> https://bengo.is/work/jokes/did.json
@bengo @robin @evan I should have made a long bet with a certain t or k that I won't summon here: I don't think anyone who's not a technologist-by-trade will *ever* use a URL with path separators as a meaningful human-level identifier for another human. I haven't seen evidence of it yet, to be sure, but would have happily made that bet 15 years ago.
As a bonus side-bet, *even if* someone matching that description did do that, they won't have done it securely*.
@bengo @robin @evan (i.e. with knowledge of the security properties of the url).
All this matters because the human level identifiers in our systems need to be understandable and usable by end-users. Underlying identifiers can be anything, paths seem sensible there (but in practice could probably be opaque hashes or whatever).
@bengo @evan @robin yeah, agreed. I think ideally you basically have one "profile" format and just link to that.
We won't get into the extensive discussions that were had historically about all of this being access controlled, so that providing a proof-of-identity along with the profile request would enable dynamic profile responses ("{x@y.com} is asking for access to your photos [ap endpoint]")
@chadkoh @bengo @evan @robin not especially different; there are *many* ways to slice this problem, I was just pointing at the possibility of name-based-interop. Right now we seem to have this weird-to-me situation where one name = one feed. Given that we (or, at least, I) have dozens of social and data profiles, that part seems unsustainable, especially in light of @evan's original point re: BYOD (since domain costs are *increasing* it seems unlikely that lay-individuals are going to BTO)
@volkris @bengo Indeed, it's a simple layering situation. If you have an ATP implementation, you can go ahead and implement AP on top of it (i.e. using that implementation's primitives). That's what ATP is designed for, in fact.
The reverse — AP over ATP — I'm not even sure what it would mean?