#social 2021-01-25
2021-01-25 UTC
melody, how, Grishka and sl007 joined the channel
# 
sl007 re: Unfortunately in reality it is not like email in reality because neither mastodon nor pixelfed use C2S or the email like addressing in the client …
# Grishka I said it once and I'll say it again, C2S prevents any semblance of a sensible UX
# Grishka besides, many servers (including smithereen) have database schemas that would make it a real pita to support
# Grishka IMO it's much better for everyone when there are domain-specific client APIs
# Grishka for example, the mastodon API has become a de-facto standard for microblogging servers
# sl007 Interesting opinion. I thank pleroma, immers, go-fed, AndStatus, redaktor and all the others for using C2S and Chris for demos! https://socialhub.activitypub.rocks/t/implementing-activitypub-client-to-server/981
# sl007 And I thank nightpool[m] for the words about this from SAT https://www.w3.org/2021/01/23-social-minutes.html
Grishka joined the channel; RRSAgent left the channel
sl007 and tantek joined the channel
# nightpool[m] i think in a world were many companies are adapting a "backend-for-frontend" type architecture powered by generic APIs—often GraphQL, ActivityPub c2s has a clear and obvious place in the ecosystem
# nightpool[m] * i think in a world where many companies are adapting a "backend-for-frontend" type architecture powered by generic APIs—often GraphQL—ActivityPub c2s has a clear and obvious place in the ecosystem
Grishka joined the channel
# Grishka As I see it, there can basically be two kinds of setups:
# Grishka - a dumb server and a smart client — here the server only does the bare minimum, authenticating users, storing objects and follow relationships, this is where c2s would work, but I'm not aware of any such implementations as of right now
# Grishka - a smart server and a dumb client — the kind of thing Mastodon is, for example
# Grishka Otherwise, if you try to add c2s to a "smart server", especially without any sort of capability negotiation, you end up with this Rube Goldberg machine of a client API when both the client and the server do too much too inefficiently.
# nightpool[m] For the purposes of very limited clients like mobile or static websites, you could also add: 1) dumb server, 2) smart server 3) dumb client
# nightpool[m] i.e. dumb server <-> smart server <-> dumb client
# nightpool[m] But yes, I agree generally that you need a dumb server somewhere in the mix for C2S to make any sense
# nightpool[m] For Mastodon, the question would be whether we want to/can expose the low-level APIs that would allow mastodon to be a more generic, "dumb" server while still having the higher level APIs that make e.g. mobile app development possible
# nightpool[m] I'm not convinced it's impossible for us to thread that needle, we've already made strides in that direction by allowing "limited" addressing via inbox delivery, and moving away from the explicit privacy levels (driven by compatibility requests fromwith Pleroma)
# nightpool[m] * I'm not convinced it's impossible for us to thread that needle, we've already made strides in that direction by allowing "limited" addressing via inbox delivery, and moving away from the explicit privacy levels (driven by compatibility requests from Pleroma)
# Grishka Yeah that's what I meant. Also for both Smithereen and Mastodon c2s would mean some weird things like merging the notifications with the feed (both store them in separate tables) into a single collection to serve it as the inbox to the clients, only for them to split them apart again.
# Grishka It would, however, be great to have some kind of standard for client APIs.
# trwnh imagine if mastodon was an activitypub client so we could use generic servers and mastodon just re-exposed the mastodon api on top of that
# trwnh that, imo, makes the most sense if we're going to be threading needles at all
# nightpool[m] that's another approach, i just think it's not particularly technically feasible given mastodon's current architecture and codebase. You'd probably want to use something more like a new Node server or Pleroma msatodon-fe for that.
# trwnh i feel like a lot of things are going to seem difficult but it also seems like that's just the direction things are going
# trwnh it would certainly require re-architecting mastodon though, i recognize that
# nightpool[m] it would basically require rewriting mastodon, at least the backend.
# trwnh maybe in rust? ;)
# trwnh jk
# nightpool[m] at that point you're writing a different piece of software with the mastodon frontend, which is what i was gesturing at with the pleroma mastodon-fe project
# Grishka it's simply more convenient and feels more sensible to derive the architecture of your project from your vision of its UI/UX
# Grishka for Smithereen in particular, there isn't really a line between the frontend and the backend, it's fully SSR with some optional JS sprinkled on top for bells and whistles
# Grishka the "smart server that uses c2s to talk to a dumb server" approach does certainly have some emaily feeling to it tho
# trwnh feels quite natural coming from email or xmpp, for sure
# Grishka it's like a webmail app that reads the mailbox that's written to by an SMTP daemon
# trwnh clients there require *some* level of configuration
# trwnh i think activitypub has a tiny advantage over email and xmpp though because you're indirectly forced to use port 443 if you want compat with the https-speaking network, and you don't have separate imap/smtp servers to deal with. you could probably get away with just asking for a hostname like activitypub.example.org -- authorization notwithstanding, of course.
sl007, englishm, kaetahbo, melody and bigbluehat joined the channel