@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 @nolan @cwebber @sl007 @fluffy considering how some people write their AP posts like email this would simply formalize their usage.

i'm imagining client support, which would have 3 folders (Home, Local, Federated), maybe 4 if they want to include mentions/direct messages; simply ignore liking or repeating. just put a timeline or a person in the subject to send a toot/peat. I'm not sure how to handle following or unfollowing.

how does it resolve the subject as a not email? no clue probably the account type.

as a side note it'd be nice to get an AP enabled 'mailing list' application with both email and AP support.

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

@trwnh @sl007 @cwebber @nolan like I mean I can see thunderbird being an activitypub reader, or a mastodon/pleroma/etc client, but as I understand it the post mechanism itself is app-specific

Like I can post to 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

@fluffy @sl007 @cwebber @nolan i think masto/roma is entirely separate here, that's a question for integrating with the "Social" bit like twitter.

if you're integrating it into the delivery bits like email, then you would need a generic ap server and c2s replaces imap.

@trwnh @sl007 @cwebber @nolan okay so does activitypub provide some generic GET/POST mechanism using bearer tokens or something? that's the part I was missing

@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)

@fluffy @sl007 @cwebber @nolan activitypub is basically this:

c2s bits:
1) POST from client to your actor's outbox (send)
2) GET from client to your actor's inbox (receive)

s2s bits:
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.

@trwnh @sl007 @cwebber @nolan okay, I didn't realize the API for the actual c2s part was specified so uniformly, and that's where my confusion was coming from.

I guess Thunderbird would still have to have different mechanisms for the various auth models, though? But that's a much more tractable problem.

@trwnh @sl007 @cwebber @nolan and I suppose supporting the c2s auth is really just a matter of supporting as many HTTP 401 login flows as possible, and Thunderbird's already sorta based on a browser so that seems a lot more feasible :)

@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 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 similar to
- i have an actor
- i have an inbox
- i have an 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 in that sense is an activitypub client interfacing with the activitypub server.

the client must first discover my actor id. i can either provide it with 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

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 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 is effectively like an SQL query for all Note objects in my outbox at

@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.

Show more

@fluffy im planning a pure ap server that just serves like...

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

Show more
Show more


just btw: we also have a very active forum, so if you have any further questions it is

@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.

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!