Notices by infinite love ⴳ (trwnh@mastodon.social), page 3

the web was not made to be federated imo because the web is not a messaging platform, it's a publishing platform. in messaging, you federate between systems; in publishing, you *syndicate* to other sites. there is a difference, and the difference matters.

@evan my point was more that “negativity” is not necessarily targeted at AP, but at the architecture and ecosystem of the present fediverse. people expressing their frustrations or criticisms should be seen as an opportunity to improve pain points at a protocol or profile level. one example is possibly spinning up a task force or report to document the lifecycles of resources and objects as they are created and deleted. another example is mapping out required properties and associated behaviors.

@evan evan, might this be an unfair framing? the activitypub specification has a lot of positives, but the problems are a) not always at the edges, and b) mostly in how popular implementation ("the fediverse") has diverged from the spec, in some places quite significantly, to the point that anyone wanting to implement "activitypub" to the letter of the spec will not be able to talk to anyone on "the fediverse". webfinger and http sigs are one thing, but the core message semantics are another.

@evan this isn't a slight against activitypub but i don't think the comparison to http makes sense. partly because activitypub in a sense *is* http, at least in how it's broadly implemented. but it's just one class of http messages. i don't think it makes sense for all web traffic to be in activitypub format.

@evan @erincandescent @julian @mikedev @silverpill If we disagree, we disagree; but my understanding developed over the past several years of thinking about this is that generic data can be presented in multiple specific ways. The UI may change, but the semantics stay the same. There are already apps that will show you your timeline as a chat messenger UI, or your conversation as a flat chronological list instead of chopped-off reply tree branches. Are they wrong?

@evan @erincandescent @julian @mikedev @silverpill Joining a Discord guild (the Group, loosely) gives you access to multiple rooms/channels (a bunch of Collections) all at the same time. Each channel could be rendered as a chat room or as a forum thread or however you want to display a collection of objects.

Essentially, `audience` and `context` are converse properties. In many cases, the "group" is the `audience` and the "thread" is the `context`. This is emergent behavior in NodeBB/Discourse.

@dansup "don't worry"? 🤨

@evan @erincandescent @julian @mikedev @silverpill historical evidence that is also relevant here:

https://github.com/w3c/activitystreams/issues/300

https://github.com/w3c/activitystreams/issues/238#issuecomment-153408442

@evan @erincandescent @julian @mikedev @silverpill Multiple collections (or any object type) can exist while sharing the same group of agents (or any other non-group set of agents) as an audience. It's not correct to say that a room "is" the group, unless you want everyone to manually join every single room one-at-a-time. The audience is the scope to which the posts (or collection of posts) are relevant, similar to how the context is the grouping. https://www.w3.org/TR/activitystreams-vocabulary/#audience-and-context

@evan @erincandescent @julian @mikedev @silverpill

1) I disagree; chat rooms, forum threads, comments sections, etc. are all just different presentations of the same generic data structure (objects in collections). I could pull the AS2 data for this entire chain of replies and render it as a chat room, or as a messenger, or however I wanted to -- flat chronological list or otherwise.

2) I would use `Group` to represent an actual group of agents. For a group of posts, I would use Collection.

@evan @erincandescent @julian @mikedev @silverpill For example, replying to a message is something that the user *explicitly chooses* to do when in the context of image boards or chat rooms. If you've ever used Discord, then you can see how in that system, it wouldn't make any sense to say that every message in a channel necessarily must be inReplyTo some other message in the channel (or anything at all). The room is a bound context.

@evan @erincandescent @julian @mikedev @silverpill Sure, it's possible to declare both a `context` being whatever grouping, and a `thread` being specifically a reply tree. (Perhaps `thread` should be renamed to `replyTree`, and `root` should be renamed to `replyTreeRoot`?)

I'm specifically against conflating the two concepts, though. I also would prefer to not give `inReplyTo` any undue deference beyond simply being metadata. For as many systems that rely on it, there are systems that don't.

@evan @erincandescent @julian @mikedev @silverpill

> Conversation threads are *usually* reply trees

this is an anti-pattern. conversations are only represented by reply trees when there isn't an actual conversation. reply trees are a poor substitute for that.

> "Comment but don't participate in thread" is a quote boost.

i'm talking about participating in a thread without responding explicitly to anything. or responding to something, but in a different thread. no one is boosting anything.

@erincandescent @julian @evan @mikedev @silverpill as far as reply trees go, it should be clear that they are not the same as a conversation or context, and inReplyTo exists completely separate and parallel to contextual grouping. the “reply tree” model falls apart the second you reply to multiple things, or reply to something in a different context, or reply and change the context, or set a context but no inReplyTo. i’m not sure why you say Announce has anything to do with it

@erincandescent @julian @evan @mikedev @silverpill …then it makes sense that the collection ought to contain items sharing the same contextual grouping. it’s similar to how hashtags are content-addressed grouping, but less purposeful, and no one owns them. the key is that even if you can’t resolve anything out of whatever is in context, you can still use it for grouping by opaque string matching. so there’s clearly defined graceful fallback.

@erincandescent @julian @evan @mikedev @silverpill i don’t think “conversational thread” is a special semantic relationship, and i certainly don’t think it is equal or equivalent to a reply tree! the basis of 7888 is that context should be used for purposeful logical grouping, as it was intended and as it ended up being used in pleroma for years. an unresolvable opaque uri is 7888-compliant. so is a collection with an owner. so is anything else. but IF it is a collection,

@evan @erincandescent @julian @mikedev @silverpill what is the “thread relationship” and how does it differ from “contextual grouping”?

@evan i know this is a timely reference to what a certain platform is doing, but blocks in ActivityPub C2S don't prevent someone from fetching your public actor data, and also have no bearing on cached, replicated, or syndicated data viewable in remote services or applications (as popularized by the "instance" model in the fediverse) unless you federate the Block activity with S2S and hope that the remote service or application understands and respects that.

@julian @silverpill @erincandescent @thisismissem Security-wise all bets are off if you want to establish anything other than “the signature claims to be from this key, and the key claims to be owned by this actor, and the actor links back to the same key, so we can assume the actor’s controller is the signing party”

note that i said “actor’s controller” and not just “actor”. this is an important distinction. just like web keys are custodial, web actors are custodial too

@erincandescent @julian @thisismissem @silverpill it matters that the key claims to be owned by an actor, and that the actor claims to own that key. the actual cryptography is merely a formality to link the http request to the public key through the private key. a “fancy password” like julian said.