#C2S

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

there is now also an english version https://changinggraph.org/en/index.html

#changinggraph #rdf #activitypub #c2s #fediverse

there is now also an english version https://changinggraph.org/en/index.html

#changinggraph #rdf #activitypub #c2s #fediverse

there is now also an english version https://changinggraph.org/en/index.html

#changinggraph #rdf #activitypub #c2s #fediverse

@steve @hongminhee

I mentioned this thread in the #ActivityPub #C2S tracking issue. I think there's a fundamental risk that C2S is going sideways because of misconceptions between devs on where things are / should be headed.

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130#issuecomment-11737818

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

@steve @hongminhee

I mentioned this thread in the #ActivityPub #C2S tracking issue. I think there's a fundamental risk that C2S is going sideways because of misconceptions between devs on where things are / should be headed.

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130#issuecomment-11737818

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

(digital) doodling a little

#c2s #activitypub #ios #fediverse #wordpress

(digital) doodling a little

#c2s #activitypub #ios #fediverse #wordpress

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

The intro to HDA (Hypermedia-Driven Applications) I've been raving about today seems relevant to the ongoing discussions about C2S APIs for the fediverse, especially the proliferation of the monolithic server+web-app antipattern. I've started a SH topic on it;

https://socialhub.activitypub.rocks/t/could-hypermedia-driven-application-architecture-be-useful-for-ap-c2s/8521

But SH seems like a ghost town ATM. Tried to post on ActivityPub.space but their interface hates my mobile browser (Fennec from F-Droid) 🤷‍♂️

#FediDevs #ActivityPub #C2S

ActivityPub client developer experience is something like this.

Building a coherent feed with stateful objects requires comparing an Activity from the inbox, with what’s in your outbox.

#ActivityPub #c2s #DevEx

ActivityPub client developer experience is something like this.

Building a coherent feed with stateful objects requires comparing an Activity from the inbox, with what’s in your outbox.

#ActivityPub #c2s #DevEx

I opened a issue in the swicg ActivityPub API repo about a gap i keep running into: how does a C2S client access server-local metadata about foreign objects?

Thread collections, read status, notifications — your server knows things about remote objects that the client needs, but AP has no vocabulary for it.

https://github.com/swicg/activitypub-api/issues/60

#ActivityPub #Fediverse #C2S

@evanprodromou

Have I already mentioned that the “Show thread” request is slowly driving me crazy?

#c2s #activityPub #fep7888

Have I already mentioned that the “Show thread” request is slowly driving me crazy?

#c2s #activityPub #fep7888

I opened a issue in the swicg ActivityPub API repo about a gap i keep running into: how does a C2S client access server-local metadata about foreign objects?

Thread collections, read status, notifications — your server knows things about remote objects that the client needs, but AP has no vocabulary for it.

https://github.com/swicg/activitypub-api/issues/60

#ActivityPub #Fediverse #C2S

@evanprodromou

@django @evan @liaizon

Hey, this is great. It is so nice to see the uptick of interest in the #C2S part of #ActivityPub. Very uplifting and gives me hope for the future of #fediverse.

I really liked your #FOSDEM presentation, and thank you for mentioning my humble list. They are just notes atm, but I will try to keep them up-to-date. I just made a bunch of updates..

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

Would love to hear more on what are the particular plans and goals for your project in the near future?

@django @evan @liaizon

Hey, this is great. It is so nice to see the uptick of interest in the #C2S part of #ActivityPub. Very uplifting and gives me hope for the future of #fediverse.

I really liked your #FOSDEM presentation, and thank you for mentioning my humble list. They are just notes atm, but I will try to keep them up-to-date. I just made a bunch of updates..

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

Would love to hear more on what are the particular plans and goals for your project in the near future?

@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

Bring it on!

#ActivityPub Social API is getting a lot of attention and traction on the implementation side! 🎉

Join the fun, in this area where there's a fine future for the #fediverse social networking.

Some new updates to the list of client-to-server #C2S parts of the AP open standard:

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

Added the projects of @kopper and a new C2S article by @django

Bring it on!

#ActivityPub Social API is getting a lot of attention and traction on the implementation side! 🎉

Join the fun, in this area where there's a fine future for the #fediverse social networking.

Some new updates to the list of client-to-server #C2S parts of the AP open standard:

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

Added the projects of @kopper and a new C2S article by @django

@pfefferle @steve @mariusor

This is wonderful! I updated my #ActivityPub #C2S notes with link to the PR..

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

thanks to the awesome support of @steve and @mariusor the #WordPress #ActivityPub #C2S API support is quite solid now.

It is possible to publish a new post, comment to posts and other comments and to follow others.

https://github.com/Automattic/wordpress-activitypub/pull/2851

thanks to the awesome support of @steve and @mariusor the #WordPress #ActivityPub #C2S API support is quite solid now.

It is possible to publish a new post, comment to posts and other comments and to follow others.

https://github.com/Automattic/wordpress-activitypub/pull/2851

thanks to the awesome support of @steve and @mariusor the #WordPress #ActivityPub #C2S API support is quite solid now.

It is possible to publish a new post, comment to posts and other comments and to follow others.

https://github.com/Automattic/wordpress-activitypub/pull/2851

@i47i @HolosSocial @apps

PS. I track a list of #ActivityPub #C2S implementations and didn't add #Holos till now. If I should add it, pleas let me know, or comment directly to the issue.

https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130

I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.

On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.

On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.

As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub

how can I best test an #activitypub #c2s implementation?

is there a client reference implementation?

can I already use your webclient @mediaformat ?

#wordpress #fediverse

https://github.com/Automattic/wordpress-activitypub/pull/2851

We have to go back #activitypub #c2s

We have to go back #activitypub #c2s

We have to go back #activitypub #c2s

We have to go back #activitypub #c2s

We have to go back #activitypub #c2s

@mapache Nice, I'm adding this to my growing list of features possible for servers supporting the Client to Server API 😉

#c2s #socialweb #fosdem

deep dive into the oauth RFCs this morning ☕

#c2s

What does an ActivityPub client look like when the server does NOT support the `proxyUrl` endpoint?

Imagine having to visually parse a URL to guess who a post is from...

#ActivityPub #c2s

What does an ActivityPub client look like when the server does NOT support the `proxyUrl` endpoint?

Imagine having to visually parse a URL to guess who a post is from...

#ActivityPub #c2s

@DaddyR @django @resl

Fabulous! I took note in the #ActivityPub #C2S tracking issue I keep on the delightful #fediverse experience curated list.

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130#issuecomment-9083289

I’ll be discussing #ActivityPub #c2s api at #fosdem

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

I’ll be discussing #ActivityPub #c2s api at #fosdem

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

@steffen @feb

/
@crossgolf_rebel @fasnix @wuffel
Was ist mit Euch?

Es kann ganz allgemein im w3 "Big Blue Button" starten [Nutzende, Entwickelnde, Fördernde egal] und bei Interesse könnten wir dann taskforces bilden.
#fediverse #activitypub #interop #c2s
Würde dann 1 Aufruf starten …
policy wie immer, be excellent, no nazis und so :)

For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.

The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni

For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.

The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni

For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.

The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni

@jdt very nice!

To what extent are you, or do you intent to, support the #ActivityPub #C2S parts of the spec? I am keeping track of a list of projects who do, at:

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

@jdt very nice!

To what extent are you, or do you intent to, support the #ActivityPub #C2S parts of the spec? I am keeping track of a list of projects who do, at:

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

ActivityPub client development is coming along!

AP platform developers be warned, I be opening issues in your repo soon.

#ActivityPub #c2s

@django if there are any updates to make to this issue on #ActivityPub #C2S .. do not hesitate to comment :)

https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130

sorry Pleroma devs, I just opened up a 2nd #c2s issue in barely a week, and I have no idea what the project capacity is.

#ActivityPub #Pleroma

ActivityPub client development is coming along!

AP platform developers be warned, I be opening issues in your repo soon.

#ActivityPub #c2s

ActivityPub client development is coming along!

AP platform developers be warned, I be opening issues in your repo soon.

#ActivityPub #c2s

ActivityPub client development is coming along!

AP platform developers be warned, I be opening issues in your repo soon.

#ActivityPub #c2s

ActivityPub client development is coming along!

AP platform developers be warned, I be opening issues in your repo soon.

#ActivityPub #c2s

ActivityPub client development is coming along!

AP platform developers be warned, I be opening issues in your repo soon.

#ActivityPub #c2s

@django if there are any updates to make to this issue on #ActivityPub #C2S .. do not hesitate to comment :)

https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130

sorry Pleroma devs, I just opened up a 2nd #c2s issue in barely a week, and I have no idea what the project capacity is.

#ActivityPub #Pleroma

ActivityPub client development is coming along!

AP platform developers be warned, I be opening issues in your repo soon.

#ActivityPub #c2s

If I wanted to mess around with ActivityPub c2s clients what's a server I can host that has support for it?

In this Codeberg issue @thisismissem wonders..

> "Has anyone done an assessment of the authentication mechanisms and standards used by each of these [C2S] implementations?

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130#issuecomment-7554760

I will bring this to a #SocialHub topic later this week, if I don't forget (otherwise remind me :)

#SX #ActivityPub #C2S #fediverse

If I wanted to mess around with ActivityPub c2s clients what's a server I can host that has support for it?

If I wanted to mess around with ActivityPub c2s clients what's a server I can host that has support for it?

If I wanted to mess around with ActivityPub c2s clients what's a server I can host that has support for it?

If I wanted to mess around with ActivityPub c2s clients what's a server I can host that has support for it?

ActivityPub: Client to Server endpoint discovery

I’ve re-started building with ActivityPub’s #c2s API based app. So this post is to document some of the challenges and hiccups.

1. The very first thing a user will want to do is login, right? So, we ask the user for their instance URL or their handle (webfinger: user@domain.tld).
2. Our app then needs to find an info about how to connect to the site.

   Luckily, the OAuth 2.0 standard exists! In our case we would be looking to RFC 8414: OAuth 2.0 Authorization Server Metadata. The main point is that once we have a server URL, we can look up the configuration routes via a predictable URL /.well-known/oauth-authorization-server

   If this route doesn’t exist then we have some alternatives. We could look for the instance actor.

   Depending on implementation, we might find this via nodeinfo (FEP-2677), or we might find it via webfinger (FEP-d556).

   1. The nodeinfo route is the more convoluted one, because fetching example.social/.well-known/nodeinfo we potentially receive a payload with links to version 2.0, and or 2.1. example.social/nodeinfo/2.1.

      This would lead us to parsing nodeinfo’s metadata field, looking for staffAccounts which would be an array, let’s just take the first one.

   2. The webfinger route would be: example.social/.well-known/webfinger?resource=https://example.social

      From there we parse the webfinger links field which is an array, looking for an object whose has rel=”self” and whose type="application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"".

      Whew, this object’s href value leads us to the instance actor.

   3. Finally, we arrive at an actor profile, where we will look for the endpoints field, and hope to find*:
      • oauthRegistrationEndpoint
      • oauthAuthorizationEndpoint
      • oauthTokenEndpoint
      • *However here too the road can be fraught with dangers… a number of servers are not allowing CORS requests on actor profiles.

        If implementations aren’t serving an oauth discovery endpoint RFC8414, and are limiting requests to actor pages, then there is really not much we can do!

• FEP-d556: Server-Level Actor Discovery Using WebFinger
• FEP-2677: Identifying the Application Actor
• FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API

#c2s

ActivityPub: Client to Server endpoint discovery

I’ve re-started building with ActivityPub’s #c2s API based app. So this post is to document some of the challenges and hiccups.

1. The very first thing a user will want to do is login, right? So, we ask the user for their instance URL or their handle (webfinger: user@domain.tld).
2. Our app then needs to find an info about how to connect to the site.

   Luckily, the OAuth 2.0 standard exists! In our case we would be looking to RFC 8414: OAuth 2.0 Authorization Server Metadata. The main point is that once we have a server URL, we can look up the configuration routes via a predictable URL /.well-known/oauth-authorization-server

   If this route doesn’t exist then we have some alternatives. We could look for the instance actor.

   Depending on implementation, we might find this via nodeinfo (FEP-2677), or we might find it via webfinger (FEP-d556).

   1. The nodeinfo route is the more convoluted one, because fetching example.social/.well-known/nodeinfo we potentially receive a payload with links to version 2.0, and or 2.1. example.social/nodeinfo/2.1.

      This would lead us to parsing nodeinfo’s metadata field, looking for staffAccounts which would be an array, let’s just take the first one.

   2. The webfinger route would be: example.social/.well-known/webfinger?resource=https://example.social

      From there we parse the webfinger links field which is an array, looking for an object whose has rel=”self” and whose type="application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"".

      Whew, this object’s href value leads us to the instance actor.

   3. Finally, we arrive at an actor profile, where we will look for the endpoints field, and hope to find*:
      • oauthRegistrationEndpoint
      • oauthAuthorizationEndpoint
      • oauthTokenEndpoint
      • *However here too the road can be fraught with dangers… a number of servers are not allowing CORS requests on actor profiles.

        If implementations aren’t serving an oauth discovery endpoint RFC8414, and are limiting requests to actor pages, then there is really not much we can do!

• FEP-d556: Server-Level Actor Discovery Using WebFinger
• FEP-2677: Identifying the Application Actor
• FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API

#c2s

ActivityPub: Client to Server endpoint discovery

I’ve re-started building with ActivityPub’s #c2s API based app. So this post is to document some of the challenges and hiccups.

1. The very first thing a user will want to do is login, right? So, we ask the user for their instance URL or their handle (webfinger: user@domain.tld).
2. Our app then needs to find an info about how to connect to the site.

   Luckily, the OAuth 2.0 standard exists! In our case we would be looking to RFC 8414: OAuth 2.0 Authorization Server Metadata. The main point is that once we have a server URL, we can look up the configuration routes via a predictable URL /.well-known/oauth-authorization-server

   If this route doesn’t exist then we have some alternatives. We could look for the instance actor.

   Depending on implementation, we might find this via nodeinfo (FEP-2677), or we might find it via webfinger (FEP-d556).

   1. The nodeinfo route is the more convoluted one, because fetching example.social/.well-known/nodeinfo we potentially receive a payload with links to version 2.0, and or 2.1. example.social/nodeinfo/2.1.

      This would lead us to parsing nodeinfo’s metadata field, looking for staffAccounts which would be an array, let’s just take the first one.

   2. The webfinger route would be: example.social/.well-known/webfinger?resource=https://example.social

      From there we parse the webfinger links field which is an array, looking for an object whose has rel=”self” and whose type="application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"".

      Whew, this object’s href value leads us to the instance actor.

   3. Finally, we arrive at an actor profile, where we will look for the endpoints field, and hope to find*:
      • oauthRegistrationEndpoint
      • oauthAuthorizationEndpoint
      • oauthTokenEndpoint
      • *However here too the road can be fraught with dangers… a number of servers are not allowing CORS requests on actor profiles.

        If implementations aren’t serving an oauth discovery endpoint RFC8414, and are limiting requests to actor pages, then there is really not much we can do!

• FEP-d556: Server-Level Actor Discovery Using WebFinger
• FEP-2677: Identifying the Application Actor
• FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API

#c2s

"A core objective of Flowz is flexibility and graceful degradation. Even when connected to a server that supports only the minimal core C2S functionality, the client still delivers a reasonable user experience. Users can perform essential actions such as reading timelines and posting updates. However, where Flowz really shines is when it connects to servers that offer extended C2S capabilities."

@stevebate, 2025

https://www.stevebate.net/activitypub-client-api-a-way-forward/

(1/3)

#ActivityPub #C2S #Flowz

"A core objective of Flowz is flexibility and graceful degradation. Even when connected to a server that supports only the minimal core C2S functionality, the client still delivers a reasonable user experience. Users can perform essential actions such as reading timelines and posting updates. However, where Flowz really shines is when it connects to servers that offer extended C2S capabilities."

@stevebate, 2025

https://www.stevebate.net/activitypub-client-api-a-way-forward/

(1/3)

#ActivityPub #C2S #Flowz

Lists like https://codeberg.org/fediverse/delightful-fediverse-experience show several server projects for #activitypub , a few that list #c2s but haven't had much luck finding a list of apps that support c2s. I guess it's a chicken/egg problem in many ways. I'd sometimes like to experiment with my own c2s+s2s server implementation, but it's a bit of a larger hurdle if there aren't any c2s desktop/mobile apps to help test with. 🤔

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

@strypey @rakoo @benpate @jupiter_rowland True that. Has anyone even got an alpha version of a #c2s app running?

People keep pointing out the UX fail of expecting people to have multiple accounts to use all the different fedi services. But that wouldn't be true if every #AP app and server used a general purpose #C2S API, defined in the AP spec (whether the existing one or not).

Then we could, for example, use a Mastodon account to login to a PeerTube service to browse and post videos. Or use a PT account to login to a Mastodon service to browse and post Notes.

@tchambers @rakoo @benpate @jupiter_rowland

People keep pointing out the UX fail of expecting people to have multiple accounts to use all the different fedi services. But that wouldn't be true if every #AP app and server used a general purpose #C2S API, defined in the AP spec (whether the existing one or not).

Then we could, for example, use a Mastodon account to login to a PeerTube service to browse and post videos. Or use a PT account to login to a Mastodon service to browse and post Notes.

@tchambers @rakoo @benpate @jupiter_rowland

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev