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