"how to not regret c2s"

[kopper@not-brain.d.on-t.work]

"how to not regret c2s"
w.on-t.work/activitypub/c2s

my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever

#activityPub #fediDevs

[doskel@masto.doskel.net]

@kopper tbh I always got the idea this was the only good way to use AP given the nature of it using rdf and just begging for extensible content

[nelson@wetdry.world]

@kopper should i read this if i'm not working with AP

i was considering whether i should just do c2s versia

[kopper@not-brain.d.on-t.work]

@nelson given the architecture i'm proposing is effectively the atproto PDS/AppView split, i don't think there's too much that's activitypub-specific here

[smallcircles@social.coop]

@kopper @nelson

This is marvelous. I wasn't aware of your project, but now I am and added it to the #ActivityPub #C2S tracking list.

I've also lined up #Outpost for inclusion on the delightful #fediverse curated lists at https://delightful.coding.social

[kopper@not-brain.d.on-t.work]

did some minor updates, no clue if the cached view updated yet but you can read the diff here if you already read the article before:

codeberg.org/KittyShopper/w.on-t.work/commit/5e22c16b6df73b8c36cba07171ffe8a0b509aa32

[hipsterelectron@circumstances.run]

@kopper unfortunately not the point but this is easily the craziest css i've ever seen. bravo

[amy@sk.girlthi.ng]

@kopper@not-brain.d.on-t.work 1am rants are always peak writing

[fiore@brain.worm.pink]

@kopper@not-brain.d.on-t.work what does c2s mean in this context ?

[kopper@not-brain.d.on-t.work]

@fiore activitypub client-to-server

[fiore@brain.worm.pink]

@kopper@not-brain.d.on-t.work isnt that how AP usually works ? ( im stupid but interested )

[kopper@not-brain.d.on-t.work]

@fiore no not really. usually only the server-to-server bit is used and (microblogging) client apps use mastodon's bespoke api

[fiore@brain.worm.pink]

@kopper@not-brain.d.on-t.work oh yea ok makes sense . this seems cool ill check it out ^^

[kopper@not-brain.d.on-t.work]

another minor update, fixing a few typos and linking a few more things. also toned down the snark cuz i've been enough of a dick already

codeberg.org/KittyShopper/w.on-t.work/commit/d998852290e9652f4511108ea2b8729d5e148205

[lina@tech.lgbt]

@kopper not a complaint but i do find it interesting that like this we would have "instances" be similar to bsky PDS [probably with a lot of differences re: federation but] and the "clients" like their appview[-s] + whatever was the name for the feed curator/moderation thing

[alexia@shrimp.starlightnet.work]

@kopper haven't read the full thing but so far I very much like this

[kopper@not-brain.d.on-t.work]

@lina yeah it's effectively the same architecture, i did have an explicit mention of that but removed it as it was attached to some unnecessary snark

[kopper@not-brain.d.on-t.work]

i should open issues on github.com/swicg/activitypub-api/issues for all my proposals and end up committing 10 faux pas in a row because they still havent decided on if they want a monolithic One Server that replaces the mastodon api or something actually worthwhile to implement

[volpeon@icy.wyvern.rip]

@kopper Your opinions are pretty much the same as mine. That's always how I approached my own instance server projects before the requirements inevitably grew way over my head haha

[kopper@not-brain.d.on-t.work]

also unrelated but i may as well throw this in here since i keep thinking about it but. doing c2s this way also opens your client up to being multi-protocol. say you want to be like wafrn and federate both via ap and atproto, you can then plug in PDSs the same way you plugged in AP C2S servers. your own client can then merge both into one

this does lose a handful of the benefits some features mentioned would bring. you would need to store all the data yourself as you'll need your own common API format, you'd need to maintain your own login tokens, your backend would need to act as a proxy for writing to the PDS/C2S server which enables you to cut that off completely if you "go evil". i did touch upon these downsides on w.on-t.work/this-tall-to-interoperate

or alternatively, you could have a "personal bridgy" which can be both a c2s client and an atproto client/appview and bridge the objects of an individual actor, irrelevant of which client is used to create them in either direction, but bridging like this isn't really interop because e.g. replies from the other network would not be visible without client support