The challenge is that the baseline features of activitypub are essentially impossible to build an effective client off of.
It's not just they are defining their own interfaces, it is that they _have_ to define their own interfaces if they want to be even reasonably effective at their chosen tasks at scale because of the limitations on how collections can be dereferenced
There are ways around this with FEPs and such, but it's not in the protocol
@hrefna
Moreover, if a protocol as all-encompassing as ActivityPub/ActivityStreams would need to first standardize a feature to the protocol foundations before anyone could implement that feature for their service, absolutely nothing could ever be done. It's hard enough today with so much of what has been defined in the protocol being so vague.
Standards-track RFCs require several implementations for a reason.
@oranadoz @mariusor @helge @risottobias
One thing that I think that ATProto is doing interesting things with in this space is separating these concerns. Basically by allowing the definition of applications (some would term them profiles) with dedicated semantics for how to declare them and interface with them. So you can define your own (RPCish) methods for actions on top of the protocol.
We could do something similar with AP, but it's a really hard thing to do retroactively.
@hrefna @osma @oranadoz @mariusor @helge @risottobias
For those interested to ponder #ATProto + #ActivityPub ... at #SocialHub we have a discussion thread about @robin article on the subject:
https://socialhub.activitypub.rocks/t/robin-berjon-running-activitypub-over-atproto/3707
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)
@mnot @evan @bengo @robin fair; I guess to elaborate, having "sufficiently good" protocols is a necessary precondition. Maybe to rephrase, "[transport] protocols are relatively easy, both to invent and iterate" because we can change/improve them transparently to the user while "it's *hard* to drive adoption of naming conventions" since their adoption is solely user-driven.
@blaine @mnot @evan @bengo Mulling this over, I think I see this somewhat differently. For the most part, *transport* doesn't matter if it moves things the way you want them to move (both IP and IPFS have shown this, in different ways). But protocols aren't about the transport, they're about the interface. And interfaces matter a whole damn lot.
@blaine @mnot @evan @bengo I reckon you can say that SMS/WhatsApp/Signal/whatever doesn't matter but that's because if you squint those are transports for the same interface.
But what if the interface is wrong? Or what if it's amorphous?
The AP/AT thought experiment isn't about piping SMS over Signal. That would be boring AF. It's about kicking the tyres on how a PDS can change the architecture of how some web things like AP are built, near-transparently but also usefully.
@blaine @mnot @evan @bengo Imagine AP but you don't have to worry about instances. Now imagine that times several protocols. Now what if those protocols can work together, thanks to interoperable formats and identity?
With that kind of foundation, we can make it very easy to experiment with new protocols that have completely different interfaces.
@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?