@sl007 @cwebber @nolan I’m not clear on how thunderbird would fit into activitypub. Is it just they it’s going to become a subscribe-only client possibly with a mechanism for responding via some other activitypub service using OAuth or something?

@trwnh @sl007 @cwebber @nolan isn’t c2s more of an oauth concept than an activitypub concept?

@fluffy @sl007 @cwebber @nolan no? auth is totally unspecced. c2s is basically just "POST to outbox and the server will take care of it, GET your inbox to read what's in it".

for the server, "taking care of it" involves assigning an id to the object and returning it to you, as well as parsing to/cc and delivering it if applicable

@trwnh @sl007 @cwebber @nolan right but what hosts the outbox and inbox? I thought those concepts were for like how activitypub implementations talked to each other, not how the client talks to the activitypub implementation.

I am probably very confused by something in activitypub as usual though.

@fluffy @sl007 @cwebber @nolan the server has the actor, objects, outbox and inbox.

the client GETs your actor inbox and POSTs to your actor outbox

it's up to the client to remember which ids map to which objects.

@trwnh @sl007 @cwebber @nolan okay so like the Mastodon web frontend is using the GET/POST stuff to talk to the various parts of the backend, then? I thought it was using some Masto-specific OAuth-based API for that.

@trwnh @sl007 @cwebber @nolan okay never mind I found blog.joinmastodon.org/2018/06/ which seems to answer my questions well enough, or at least gives me a better starting point for understanding

@fluffy Mastodon is a monolithic app and doesn't implement separate c2s/s2s bits. it's actually not strictly an activitypub server; it just transforms and serializes activitypub documents for federation only.

a "pure" activitypub server/client would basically work just like email.

imagine ap.trwnh.com similar to mail.trwnh.com:
- i have an actor ap.trwnh.com/actors/1
- i have an inbox ap.trwnh.com/actors/1/inbox
- i have an outbox ap.trwnh.com/actors/1/outbox

separately, i have a client app

@fluffy i can run the client on localhost, or i can run it as a separate server, e.g. living at www.trwnh.com. in that sense www.trwnh.com is an activitypub client interfacing with ap.trwnh.com the activitypub server.

the client must first discover my actor id. i can either provide it with ap.trwnh.com/actors/1 or more realistically i see webfinger being used for mapping user@domain to id as a de facto standard (you could also map phone numbers, email addresses, etc -- webfinger uses any uri)

@fluffy once the client has the actor id, it gets the inbox/outbox endpoints

the client POSTs to your outbox (using whatever auth mechanism is supported) an object with addressing. the server responds with 201 Created and the id of the Create activity, which also assigns an id to the nested object. the client parses that response and stores the activity in local storage

@fluffy see also w3.org/TR/activitypub/#client-

the server then processes to/cc if available, and delivers to those inboxes.

how does the client discover ids? that's left unspecified, but in practice the answer is usually webfinger resolution

how does the c2s do auth? also unspecified, could be oauth, could be simple password, could be some newfangled ocap thing. could be UNIX user ACL if you wanted to do it like email (does the current user have rwx)

@fluffy the problem i'd like to figure out more is auth, and particularly cross-domain auth. i can wrap my head around it if everything is done out-of-band, but that's not exactly straightforward ux to say "here's this token that you should use if you want to GET this restricted collection/object"

@fluffy i actually think it's easier to handle auth at the *client app* level, and basically just do oob token generation for every client app you want to set up as a server.

@trwnh Yeah that doesn't sound too different from how MicroPub works with IndieAuth for its auth, although IndieAuth is AIUI all entirely based on bearer tokens for that flow (and that's also where the experimental s2s stuff is supposed to happen for AutoAuth, but there aren't any actual useful implementations of AutoAuth yet)

@trwnh I keep feeling like I want to add native ActivityPub support to Publ (my own CMS) but there's just so much stuff I'd have to do, but the end result would be way better than the piecemeal partial solution I have using fed.brid.gy right now. Like I want real post privacy controls in it, and having a ActivityPub client support for managing posts and interactions would be really nice.

@fluffy for the most part i've been trying to plan it out as i described it above with www. and ap. except i'd be running www on the root domain.

essentially i realized this when i had to consider the problem of URI namespace overlaps. how do you know which urls your client app can't use because they conflict with the server, if they're running on the same FQDN? answer: don't run them on the same FQDN. you can proxy if you want, but the ap server is basically just store-and-deliver.


@trwnh Hmm, and I suppose that ActivityPub would be able to do things like decoupling actors from their profile/publishing pages? One of the things I'm less than thrilled with in IndieWeb is how the domain name IS the identity, end of story. It's a nice simplifying assumption but it leads to all sorts of shitty edge cases.

@fluffy yeah assume trwnh.com/notes is effectively like an SQL query for all Note objects in my outbox at ap.trwnh.com/actors/1/outbox

@trwnh yeah and I think a Publ context could kinda-sorta do something similar, although Publ is more like... site-centric, interchange-second. Because for me it's more about providing a website that has social aspects, rather than providing a social experience that has a website, if that makes any sense.

Like the primary UX on a Publ site is the web browser, but I want to be able to support alternate means of accessing it as well. I've mostly focused on Atom but, y'know.

@trwnh the great thing with Publ is everything is template-driven and so in theory it seems like I could support the outbox with a template that just emits JSON-LD instead of HTML (and like my Atom stuff is just a template that emits XML for example)

@fluffy im planning a pure ap server that just serves like... ap.trwnh.com/uuid

the ap spec says object ids SHOULD be assigned within the actor namespace but i think i'd like to support changing ownership without changing id

@trwnh yeah I wish more stuff were UUID-based rather than URI-based. And that's a thing I have within Publ, although currently it's only really used in Atom templates (like there's currently no way to look up an object based on UUID, although I could add that pretty easily if I ever have a use case).

@fluffy the security is in not knowing what the id uri is? and in never exposing it directly. that basically punts the problem of access control down to the website

i really may want to add oob oauth though, i just dont know how to make that mesh with actors yet

@trwnh Publ's auth model is primarily based on restricted access to objects based on ACLs. Secret URIs are also doable but like, right now if you try to access an entry page that you don't have access to it serves up a 401 with a WWW-Authorization bearer/realm header if you're not logged in, or a 403 if you are, and a mixed content page (index etc.) will add WWW-Authorization if you're not logged in but logging in could present more stuff.

@trwnh So that works in the AutoAuth context, which is only like, theoretically supported, and also you can use e.g. a feed reader with a shared cookie jar to get at the content in the Atom feed or h-feed or whatever (and my auth stuff supports way more than just IndieAuth)

@trwnh in an ActivityPub context I was going to also just do the Mastodon thing and only send out push notifications to the inboxes of actors who have authorization to see the thing.

@trwnh also templates can choose to show "stub" entries for unauthorized things, which I do on my Atom feeds, and to also show a "hey try logging in" notification on web views. It dosen't leak any information aside from the fact that there is in fact a private entry, which feels like an okay compromise in this chicken-and-egg world of having nothing that actually speaks any useful federated auth protocol yet.

@trwnh that said in my case, the UUIDs for private content are always public, because that's necessary for Atom. So I don't think I'll ever be able to support private/protected content backfilling via ActivityPub, but I'm not sure that's even desirable anyway? I dunno. This stuff's so messy.

@trwnh Before I implemented the ACL stuff I was just using secret, unguessable URLs and then publishing those through private sidechannels like my vent twitter and whatever. But that's annoying AF.

@trwnh So like here's an example of an entry that just requires that someone be logged in to view it, rather than needing to be in a friend ACL: beesbuzz.biz/3922

and you can see how that looks in a public/index/whatever context at beesbuzz.biz/blog/?date=201907

Sign in to participate in the conversation
Queer Party!

A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!