Discovery for Interoperability

[Sebastian]

Some of the Talks show the missing opportunity for machine-readable discovery of remote AP supporting type …

Service Capability Discovery

The S2S specification doesn’t appear to have an API for discovering what capabilities an Actor’s server supports. As an example, I happen to know that right now Mastodon doesn’t support AP features such as relationships, so I shouldn’t offer my users an option to use those features with actors running on Mastodon. If I did, the experience for my user would be confusing (“I sent Bob an Offer activity (friend request), but Bob never responded,” when Mastodon never presented Bob with the activity). …

You can see this in Come Together Right Now - A design approach to interoperability - ConfTube
and users are working on solutions.
@darius with Documenting federation behavior in a semi-standard way?
and @cjs in the Talk Go-Fed: Past, Present, and Future - ConfTube

Let us debate on how to discover …

[cjs]

Also this will be related to the “towards ap v2” session, I highly recommend attending both. Reason is, the ability to provide structural data to do discovery can also be used to generate human documentation for the community on how that software interoperates.

[how]

What about merging the two sessions? This one could become one topic of ActivityPub Experimentation: Towards AP v2.

[Sebastian]

I would not do this, please note that already this was merged Getting extensions into the ActivityStreams 2.0 namespace and there is incredible much input in “Towards AP v2” now.

This session should really be about how we could optimize federation.md towards machine readable discovery. redaktor is currently desperate and sad cause of missing interoperability and only a few caring about https://www.w3.org/TR/activitypub/#conformance

[how]

Yes, it’s already scheduled for the first slot in Room B.

[Sebastian]

Shared Notes from the session

Session: Discovery for Interoperability
Mod: cj
Participants: Michael, lain, Sebastian, Morgan, pukkamustard

What information should be machine readable?
Ex:

• Mastodon + Article
• Friendica posts ugly on Pleroma

Actors acting upon each other, not servers.
Proposal: capabilities on the Actor, not Server (somewhat superfulous)
Ex:

• Pleroma has chat messages, added field to show “this actor supports chat messages”
• System actor in Friendica.

[ Some agreement there. ]

Next question: Where to document this behavior?

Social working group?

Under what namespaces?

What process to get it documented?

Proposal: Follow-up discussion for Federation.md, described in our summary Discovery for Interoperability
and specifying it at socialhub forum first to move it to a refactored W3C Social CG

What level of detail? “This Actor accepts these exact Activities” vs “This Actor generally supports this feature”?

• Actor says “I accept this activity”
• Hard to say what the best granularity is.
• Should cover main Activity and object.

How to cover reactive types?
Ex:

• For an invitation: Accept, Reject, TentativeAccept, TentativeReject
• Friendica allows Follow on a discussion.

Consensus around initial Activities being in-scope.
Reactive Activities requires further thinking.

There should be a mechanism to explicitly say “this Activity interaction is NOT supported”.

Omitted capabilities are unknown. Because existing capabilities may already be supported, but not guaranteed. May indicate will be a SHOULD definition.

Theme: How to technically do this?
Q: Is this fetched from the Actor every time? Best practice?

• System could send Update on Actor when capabilities change.
• Existing systems cache profile information (on order of days)
• Receiving an Update can be a cache invalidation mechanism
• Not needed for S2S mechanism, but really good for user experience and C2S.

Q: List of capabilities

• Friendica shares comments w/ Actors, and is redistributed amongst other Actors

• Pleroma:

"capabilities" : {
    "acceptsChatMessages" : true
}

• Redaktor uses type’s ability to be an array: A collection is not just a collection but an additional ActivityStreams “type”, whose “items” are listed.
• Feedback: multiple types not well-supported in Fediverse
• List then becomes a list of types and links to their documentation.
• Types should have “full URLs” like https://www.w3.org/ns/activitystreams#Question

Ex: “capabilities”: [{type1}, {type2}]
Q: What granularity of types? Activity and Object type? Create{Note} or Create?

• Need two levels: Create is level1, Create{Note} is level 2

• But is it really three levels: do something in reply to Create{Note} level 3?

• Ex: Like (in reply to something) is already level 1.

• Ex: Accept, Reject is back to level 2 or 3?

  Does this risk over-thinking? If just focusing on client interactions, just initial (re)actions are needed. But if server to server interactions, focus on complete description of actions/re-actions.

• Linked Data has complicated concept called SHACL (https://www.w3.org/TR/shacl/), but may not be needed in a client-focused area.

• When fetching an object from a remote system, can understand capabilities of the remote (fetching) system. But, may incur problems

Q: Permissions view? Do we show “general capabilities” or show a “permissions view of capabilities”?

+1 for general view

Q: How to show capabilities such as “direct message”?

• Generally not easy to deal with in Pleroma, hence push for Chat.
• Friendica’s Direct Message code is 10 years old and quite complex

Linked Data vs non-Linked Data solutions.

In towards V2 session (to get things such as this standardized): ActivityPub Experimentation: Towards AP v2
In Room A: https://bbb.fosshost.org/b/mor-fee-7b4-2nh

We all thank CJ for the moderation