Gregory's ServerIf I were to build a new #ActivityPub project today, it would be generic.
Giving instance admins the ability to pick and choose what activities to support in a modular way would be awesome.
 22 comments
If there was a standard way to list capabilities across fediverse software, you could also transform objects to ensure compatibility and limit delivery to compatible instances. The federation.md thing is nice, but its not machine-readable. If we solved this, we could make the fediverse much more efficient!  @dansup there are various SocialHub topics on going beyond FEDERATION.md, both towards machine-readable capability discovery, and a more standardized way of documenting capabilities. @dansup no, but I know @grishka @sl007 are interested. Lemme find some of the topics.. https://socialhub.activitypub.rocks/t/discovery-for-interoperability/992 https://socialhub.activitypub.rocks/t/2021-05-01-fediverse-interest-group-meeting/1649/24 There are more mentions, also under 'nodeinfo'. Might create a new topic for the discussion.. Regarding better documentation I created this: https://socialhub.activitypub.rocks/t/improvement-to-federation-md-convention-murmurations/1573  dansup, I've been talking about this exact thing for at least a year. Like, "I would like to know in advance whether this object supports this activity". This would also make sense to combine with privacy settings, as in, "you can send this activity but only if this actor follows you". @dansup the standard way to discover capabilities will eventually be much needed. But I'm interested in what comes before: the ease-of-development of entirely new application types that are not silo's afterwards, but rather building-blocks for a more task-oriented fedi. Here thinking that AP vocab extensions represent the domain structure found by DDD and messages represent some of the events from the domain-driven design (event storming) as they travel the network. AP is wire protocol here.   @dansup no, i mean a generic Server with each google "app" being a Client. like Google Accounts, but then hooked up to Gmail and Youtube and Blogger, etc  @dansup I think that devs should offload the supported activities on the clients, not on the services side. An activitypub server should accept whatever, and then only the clients will interact/show what they support. As long as you think in terms of what your AP services supports, you'll end up with needless complexity. @mariusor Most implementations have a web client that render activities, are you saying they should support other activities (and implement C2S) that may never be exposed to the vast majority of users? I'd say the issue isn't so much C2S vs S2S, but rather having unified UI components across all clients.  Yes. Exactly this! It was exactly _right_ to get pixelfed up fast and working. That was most important to incubate fediverse but I think now it's time for generic servers (and diverse clients). About “modular”: |
I would think the modular UI components would be most challenging, as you'd have to make them interoperable with each other.
Could abstract the complexity of mapping ActivityStreams verbs + compatibility to UI components and side effects with a visual drag-n-drop tool.