Conversation

Notices

1. Embed this notice
   🫧 Social coding commons (smallcircles@social.coop)'s status on Thursday, 17-Sep-2026 22:55:01 JST 🫧 Social coding commons

   #ThoughtProvoker :blobhyperthink:

   Opt-out happens where random fedi app developers are your landlords who decide what services you get, and who were still benevolent enough to give you a choice (if you happen to find out about these services).

   Opt-in fits a public online space where you have your own home and self-sovereignty to decide the services you want to consume in your social household. It is where you have control of your own life.

   https://coding.social/blog/prosocial-web

   #SX #ProsocialWeb #ActivityPub #fediverse #consent #sovereignty #DigitAlautonomy

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Thursday, 17-Sep-2026 22:55:00 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     @smallcircles this is a very good blog post!

     I didn't see a link, so I wanted to check: are you familiar with the #Unhosted project?

     https://unhosted.org/

     I think it provides a great model for networked computing -- bring-your-own identity and storage, with an open-ended application domain. It was one of the projects that was an input to ActivityPub.

     I think the difference from the #ActivityPubApi is that AP supports activity distribution by default.

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Thursday, 17-Sep-2026 23:01:36 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     @smallcircles I think at our last meeting, we suggested the following layered architecture for #ActivityPub API work:

     - A base profile; just enough to get things working
     - A bunch of discoverable additional features, like SSE and search
     - An "advanced" profile, essentially base profile + selected features

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Thursday, 17-Sep-2026 23:05:42 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     @smallcircles the goal here would be to get server developers over the line to the basic profile. Client developers can count on the basic profile, and check for advanced features. If those advanced features aren't available, the clients can either implement workarounds or just leave out their own features that depend on those parts of the API.

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Thursday, 17-Sep-2026 23:06:43 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     @smallcircles so, for example, consider a client app that shows a map of a region, and puts pins on the map for each activity with a `location` property.

     To provide real-time updates, it could check for SSE support by the server. If it exists, the client could use it to get new activities and show them on the map. If the server doesn't support SSE, the client can re-fetch the actor outbox periodically, and use that to find new activities. Or, just skip real-time updates.

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Thursday, 17-Sep-2026 23:09:41 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     @smallcircles over time, we'd hope that more servers would have more of these features available. It would be possible to create clients without fallbacks for missing API features.

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Thursday, 17-Sep-2026 23:12:41 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     @smallcircles I think there's a virtuous cycle here. The more servers that support the ActivityPub API, the more that client developers can experiment with it -- making cool projects like Nuages.

     And the more *client* software there is, the more incentive there is for server developers to support the ActivityPub API. Especially if the base profile is very easy to implement.

     I think there's a good network effect there.