Conversation

Notices

1. Embed this notice
   Sal Rahman (manlycoffee@techhub.social)'s status on Sunday, 04-Feb-2024 16:22:03 JST Sal Rahman

   Ideally, at the bare minimum, ActivityPub should have explicitly specified the "shape" of JSON (not JSON-LD) documents.

   For example, the spec could have stipulated:

   "An Actor document MUST contain the following fields, and MAY be extended via JSON-LD contexts"

   And then also stipulate:

   "Clients SHOULD expand incoming JSON-LD documents".

   This way, applications could skip the expansions step for significantly large subset of the Fediverse.

   This is important because not all environments (languages, runtime environemnts, etc.) have the luxury of expanding JSON-LD documents.

   #ActivityPub

   • Embed this notice
     phiofx (phiofx@hachyderm.io)'s status on Sunday, 04-Feb-2024 16:22:01 JST phiofx

     in reply to

     • just small circles 🕊

     @smallcircles @manlycoffee

     It might be useful to define what different levels of interoperability mean as more diverse implementations with very different motivations and use cases enter the network (that can never fully interoperate and would not need or want it)

     There is probably something like the "minimum" interoperability that is required and useful but this is not jumping at you from the specification. Maybe thats why conformance testing is still lacking?

   • Embed this notice
     just small circles 🕊 (smallcircles@social.coop)'s status on Sunday, 04-Feb-2024 16:22:02 JST just small circles 🕊

     in reply to

     @manlycoffee given that protocol extensibility isn't well defined, protocol flavors are created all the time, protocol decay introduced (broad interop becomes ever harder). Imho there's merit in considering #ActivityPub to be JSON-first and have a JSON-LD approach for those who wanna go the extra mile.

     An extension for a particular domain requires docs/specs and validation, where JSON-LD isn't best suited. See:

     https://socialhub.activitypub.rocks/t/activitypub-a-linked-data-spec-or-json-spec-with-linked-data-profile/3647

     https://socialhub.activitypub.rocks/t/linkml-for-definition-of-activitypub-extension-schemas/3838

     https://socialhub.activitypub.rocks/t/initiative-activitypub-step-on-board-integration-guide/3542

   • Embed this notice
     phiofx (phiofx@hachyderm.io)'s status on Sunday, 04-Feb-2024 17:19:30 JST phiofx

     in reply to

     • just small circles 🕊

     @smallcircles @manlycoffee what I would ideally like to have is a layered #activitypub approach (its core, mantle, crust if we use a geological analogy) where each additional layer provides enhanced functionality and eventually things split into continental plates that do their own specialties.

     At the very core it could be something very simple, e.g., servers ping each other, exchange actor lists, basically just establish what the network is. Next level support #rss type notifications etc.

   • Embed this notice
     just small circles 🕊 (smallcircles@social.coop)'s status on Sunday, 04-Feb-2024 17:19:31 JST just small circles 🕊

     in reply to

     • phiofx

     @phiofx @manlycoffee

     In addition we often discussed that there's likely - and that's what you refer to as well - something of an ActivityPub Core, which is this minimum stuff to implement in any fedi app or service.

   • Embed this notice
     just small circles 🕊 (smallcircles@social.coop)'s status on Sunday, 04-Feb-2024 17:19:32 JST just small circles 🕊

     in reply to

     • phiofx

     @phiofx @manlycoffee

     Yes, indeed. While at the level individual apps the use cases are often domain-specific (either conform an application domain or a business domain), you can define / specify / standardize on more granular building blocks within those that could be reused in many different contexts / domains.

     I made a sketch of that idea in relation to defining Compliance Profiles on #ActivityPub endpoints. See:

     https://social.coop/@smallcircles/111724495015417087