洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · Reply to kopper :colon_three:'s post

@kopper Thanks for engaging with this—it helps me think it through more carefully.

Your point about making the split explicit at the protocol level is well taken. I can see how that matters especially for extensions: a lot of FEPs end up adding actor-global state for things that are really client concerns, and having a clearer boundary in the protocol might discourage that drift. That's a concrete benefit I hadn't fully appreciated.

On the interoperability question, I think I see where we differ. You're reframing the core promise of C2S as “reuse the same account across different interfaces,” whereas I'd been reading it as “connect any frontend to any server.” Those lead to quite different designs. I'm not sure which framing is more faithful to what C2S originally intended—maybe neither of us is wrong, and the spec was simply underspecified on this point.

That said, if account portability is the goal, I wonder whether C2S is really the right tool for it. FEP-ef61 and the Nomadic Identity approach both tackle that problem more directly, by making identifiers server-independent at the identity layer rather than standardizing the client–server protocol. It feels like a different layer of the problem altogether, and I'm not sure C2S can carry that weight on its own even with your proposed architecture.

The point about AP objects remaining AP objects through hydration is interesting though. I can see how that keeps the pieces composable even without a standardized client API. I'll have to think about that more.

kopper :colon_three:'s avatar
kopper :colon_three:

@kopper@not-brain.d.on-t.work · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee nomadic identity is interesting but orthogonal to this i believe. the advantage of my approach to c2s is that it lets you use different interfaces at the same time (which admittedly nomadic identity can also do if implemented correctly), and also lets you create frontends which can combine multiple backends together (e.g. a standalone "reply tree indexing client" you log into once to set up and that any app that wants reply trees can now call to via as:proxyUrl, apps that use a "c2s mastodon api" but also have a separate "emoji reaction indexing client" they can query to add features on top of the other api they're built for)

i have additional thoughts around nomadic identity as it currently exists (e.g.
as far as i can tell did:key is unusable as you have to give your private key to the server for it to do autonomous actions such as approving follows automatically, and since the key can not be rotated the server can now permanently impersonate you for the future), but they're not relevant to this and both nomadic identity and c2s can be done at the same time
🫧 socialcoding..'s avatar
🫧 socialcoding..

@smallcircles@social.coop · Reply to 洪 民憙 (Hong Minhee) :nonbinary:'s post

@hongminhee @kopper

I've been on the same subject the past week, making these arguments. I'd love to see protocol separated from solution design. Most recent additions to the fragmentiverse.. social.coop/@smallcircles/1161

🫧 socialcoding..'s avatar
🫧 socialcoding..

@smallcircles@social.coop · Reply to Raphael Lullis's post

@raphael @silverpill @julian @mariusor

I agree. Aboveall we need to know where protocol ends and 'app' begins. Be generally more deliberate in terminology use, and no longer talk in overloaded terms that have different unclear meanings to different people in different settings (to avoid using 'contexts' one of such overloaded words)

I've noticed for instance people having a very different notion of what a 'generic server' is, in definitions that are almost diametrical opposites.

My definition of generic is 'not specific' i.e. a generic server is a pure protocol implementation (which is something to agree upon, what that exactly entails), having no knowledge of *any* app / solution built on top of it or 'passing through' its messaging architecture.

In the other meaning a generic server 'knows/does/has it all' i.e. it understands everything we comprise to be 'the fediverse' in a kind of hard-wired fashion based on the functionalities that (marginally) interoperate today.