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

@lanodan @erincandescent so is it basically `inReplyTo` but setting a different `context`

question mainly to proponents of quote posts, but anyone can respond:

what would you say is the semantic relationship between a “quote post” and “the post being quoted”?

Are there any semantics at all, or is it a generic link/reference? What’s the difference between a “quote” and a “link preview”?

By semantic, I mean “meaning”. What does it mean to “quote” something?

If “quote posts” never existed, how would you design an equivalent?

boosts welcome, i’m trying to get a wide range of answers

@cwebber @aaronpk i... may or may not have something i'm working on, personally, that does basically this 🤐

all i'll say is that Hugo recently released a feature for "content adapters", which let you dynamically "add pages" to your static site even if they're pulled from elsewhere... where "elsewhere" can mean "local json data files" or "live http api". it's pretty cool from my toying around with it. maybe by end-of-year i can show or tell a bit more...

#TIL the query component of a URI is actually completely opaque. There is no such thing as a "query parameter" defined in any spec that I can find -- the use of ampersands to delimit such "parameters" is purely conventional!

At some point (HTML4), the recommendation was to use *semicolons* instead: https://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2

There is even a line of argument that says that query parameters are a misfeature and antipattern. Any "parameter" should be passed along with the request itself, not the URI

@dansup that's a hoarding problem xD

@dansup wait, why -10 years? not every object is freshly authored activitystreams... some objects might be historical, converted from a cms, or even just fetched 10+ years later without the activity.

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