"how to not regret c2s"w.on-t.work/activitypub/c2smy opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously.
Uncategorized
17
Posts
8
Posters
6
Views
-
@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
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
-
"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 #fediDevsdid 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 -
"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@kopper unfortunately not the point but this is easily the craziest css i've ever seen. bravo
-
"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@kopper@not-brain.d.on-t.work 1am rants are always peak writing
-
"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@kopper@not-brain.d.on-t.work what does c2s mean in this context ?
-
@kopper@not-brain.d.on-t.work what does c2s mean in this context ?
@fiore activitypub client-to-server -
"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 #fediDevsalso 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 -
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 supporti guess you could make a frontend that talks both APIs natively and picks which one to use depending on how you log in, which would avoid the going evil bit, but that increases complexity on the user's device a fair bit (likely manageable though) and still requires you to proxy the content of the other network as trying to fetch it from the client will either rate-limit/be slow or cause auth failures (e.g. an atproto login trying to fetch AP objects) -
i guess you could make a frontend that talks both APIs natively and picks which one to use depending on how you log in, which would avoid the going evil bit, but that increases complexity on the user's device a fair bit (likely manageable though) and still requires you to proxy the content of the other network as trying to fetch it from the client will either rate-limit/be slow or cause auth failures (e.g. an atproto login trying to fetch AP objects)now that i think about it, you would need actors and logins for both sides anyway if you're doing bridging, this is prolly not an issue
-
now that i think about it, you would need actors and logins for both sides anyway if you're doing bridging, this is prolly not an issuebad ideas:
xrpc/com.w3.activitystreams.proxyUrl?id=https://..{ "endpoints": { "xrpcProxyUrl": "https://..." } } -
bad ideas:
xrpc/com.w3.activitystreams.proxyUrl?id=https://..{ "endpoints": { "xrpcProxyUrl": "https://..." } }a XRPC endpoint returning AS2-compatible data would be funny
-
R relay@relay.an.exchange shared this topic
-
@jb i should look this up do lexicons have any places they can have unrestricted json in or would it have to be a string or something
-
@jb i should look this up do lexicons have any places they can have unrestricted json in or would it have to be a string or something
lexicons do have unrestricted json, lexicon validation are there but its not required
