Didn't know about Thunderbird either …
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 okay never mind I found https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/ 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
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 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.
@trwnh I do like how IndieWeb stuff is mostly just like, building blocks that you can use to put together whatever parts of the social experience you want, but that also presents a pretty big barrier to entry and like when I'm doing interactions between sites there's so many moving parts that tend to fail and go weird.
I like not having to reimplement the world for things like replies/notifications/etc. but nothing I try to use *quite* works right for my use case anyway.
@trwnh but I do like how IndieWeb stuff is all incremental on top of existing things and relatively easy to add piecemeal. Even if the end result isn't as perfectly integrated as what the vision of ActivityPub is going for.
Like I have very mixed feelings about mf2 as the interchange format but at least it's really easy to add on top of any HTML templating system. And like even Mastodon supports it to a limited extent.
@fluffy my main problem with mf2 is that html elements appear in the DOM and can't simply be metadata unless you abuse display/visibility css rules. also sometimes you *don't* want to download an entire html webpage if you just want one bit of something.
@trwnh oh I am 100% agreed with you there. I hate how much shit I have to hide on my page, and how I can't even properly do h-feed because there's no provision for having a cut/summary/more link.
@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.
A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!