@ilja ya! Good rec. I've been following it. Personally I don't love a new custom URI scheme vs just using did:, but on the whole it's a great contribution
"It was as he suspected: in a rigid hierarchy, nobody questions orders that seem to come from above, and those at the very top are so isolated from the actual work situation that they never see what is going on below. It was the chains of communication, not the means of production, that determined a social process.. Nothing signed “THE MGT.” would ever be challenged."
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@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.
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
i like to play, explore, and help people talk with computers. works on activitypub 🌎🌖 robust openness, sustainability, generosity, harmony, tranquility, resilience, freedom, dweb, web4, DID, zcap, law, peace, dukkha, criticality. {B,T}LM.