Like I can post to @beesbuzz.biz as an activitypub actor but the actual post verb/mechanism is not even remotely based on c2s in the traditional sense nor would I have any way to do one
@trwnh @sl007 @cwebber @nolan one of the difficulties I have with activitypub is it just seems so vague and yet so precise and all-encompassing and this is why I am much more interested in the IndieWeb suite of things instead (everything's just webpages with microformats, you can implement the parts you care about or make sense and ignore the rest)
1) POST from client to your actor's outbox (send)
2) GET from client to your actor's inbox (receive)
1) POST to inbox on another server (delivery)
2) GET from outbox on another server (fetch)
the exact authorization method is left unspecified. you could use bearer tokens, you could just simple username/password.
I guess Thunderbird would still have to have different mechanisms for the various auth models, though? But that's a much more tractable problem.
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 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.
@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.
@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
@sl007 FWIW I posted some thoughts earlier today. They’re in the context of Publ and integrating it (and other site generators) to ActivityPub with a better experience than what Bridgy Fed can provide. https://beesbuzz.biz/blog/4379-Im-warming-up-to-ActivityPub
A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!