FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)
-
@erincandescent @scott @julian mastodon etc are "level 0", pleroma/akkoma are "level 1", nodebb and discourse are somewhere around 2-3
-
-
@infinite love ⴳ @julian @Erin
Do we need to indicate whether you can follow a context, or would that be specified elsewhere? -
@Erin @julian @infinite love ⴳ
So, since it is not declared, we would need to check to see if the context has an inbox and outbox.
And since it is not declared, we would have to check to see what traits a particular context has.
And since it is not declared, we would have to make assumptions about whether a context is a thread (conversation container) or not.
It seems like we are doing a lot of checking when the sending platform could just tell us that information.
Sure, we can't assume they will provide that information, but if they tell me up front, that is one less server query I got to make since an if then statement can make that extra query go away. -
@scott @julian @trwnh I'm not sure I completely follow the specifics of what you're trying to discuss here, but ActivityPub is duck-typed: if it quacks like a duck, it's a duck. If it has the endpoints you need to follow it, you can do so.
If a post has an inbox and an outbox, you can follow it. If a picture has an inbox and outbox.. -
Something like this:
{
"@context": "https://www.w3.org/ns/activitystreams",
"thr": "https://purl.archive.org/socialweb/thread#",
"thread": {
"@id": "thr:thread",
"@type": "@id"
},
"root": {
"@id": "thr:root",
"@type": "@id"
}
"traits": {
"traits": "inbox, outbox, conversation, amendable"
}
}
This would let me know that it is a thread and that people can follow the context. I can then render it as a thread and potentially add a follow or subscribe button for the context.
You could also declare that it does not have an inbox and outbox, which saves me the trouble of checking myself. -
@erincandescent @scott @julian ideally you would also check for the presence of a followers collection, but fedi kind of has this bad habit of assuming things
like, going by duck typing, i would say that
- followers means you can Follow it
- likes means you can Like it
- shares means you can Announce itbut we just throw the firehose around and let the recipients sort it out
part of the issue is that activities are both notifications and also actions with side effects
-
@erincandescent @scott @julian
so the notification is the Like itself, the message that “someone liked this”
and the action is the side effect of adding to likes
you might Like an object without a likes collection, but even if you send that activity to the object’s owner, their AP server probably won’t do anything with it because the side effects are a no-op without a likes collection. (unless there’s a secret likes collection that is just undeclared on the object?)
-
@erincandescent @trwnh @evan @jenniferplusplus @mikedev @scott @julian @trwnh
The name of the property could be different, but I think it is useful to have two collections:- "Thread" is easier to implement, and in any case, software needs to keep track of reply trees, one way or another.
- "Context" is a bonus. It contains everything related to a conversation, including reactions and edits. Some applications may not need it, and for some it might be difficult to implement, so it should be optional.My estimation is that implementation of "Context" + "Thread" will require roughly the same amount of effort as implementation of "Context" alone, so for those who want "Context" this separation should not be a problem. If software doesn't keep track of activities it can provide empty "Context", but their
Addactivities should nevertheless have it intarget. Perhaps in the following form:"target": { "type": "Context", "id": "<context-collection>", "attributedTo": "<conversation-owner>", "thread": "<thread-collection>" }
