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

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

@silverpill @mikedev @julian "partial embedding" is a red herring. all embeddings are partial embeddings as far as you know. even fetching from the origin isn't guaranteed to respond with all statements/properties. (open world assumption, remember?) and you're going to have to fetch from origin anyway because you can't trust non-authoritative representations.

i think you'd be better off indexing the collections.

@julian

> collection containing an outbox

this is something i want to write about as well, but I'm not sure if it should be a separate FEP. probably it will be a separate FEP centered around Collection-Actors which recommends putting objects in the Collection and activities in the Actor's outbox. not sure what to call it exactly, but "collection-actor" is the provisional name for the idea.

@jesseplusplus @silverpill

@Gargron @evan maybe the people are wrong. maybe their expectations are shaped by hostile design of the past decade+. maybe we shouldn't replicate that design.

arguably this specific example is one of the lower-stakes ones, but "auto approve follow requests" defaulting to "true" is more accurate to what's really happening than "manually approve follower requests" defaulting to "false". spec/protocol-wise, all Follow activities need to be Accepted. that's the default flow.

@evan @erincandescent @julian @silverpill I don't think a thread *has* to be a tree -- it's a set. The "reply tree" is a separate structure. Threads can be forked out of other threads.

(I also dislike "reverse chron" and heavily favor "forward chron", but custom sorting of collections is not well-specced rn so that's a future step.)

@julian @silverpill We could define a dedicated type for Thread or Conversation or whatever you want to call "a Collection that contains only "post" objects", but it would still be a Collection as well. I think this was something I was considering for a FEP that I ended up never really writing because it felt unnecessary and also very premature. The general idea is to define some way to know what a Collection "contains" -- is it a Conversation or a MediaAlbum or whatever. The problem is taxonomy

@julian @silverpill why would anyone expect a Note/Article when fetching the URL for an entire thread/topic?

@silverpill @thisismissem @mikedev @julian yeah, the only point of difference i recall when reading about comversation containers was a bit about using target.attributedTo (FEP-400e) instead, which i would personally discourage in favor of context.attributedTo so that there is only one source of truth. aside from that, FEP-7888 certainly covers this implementation in at least spirit if not fully in letter -- the core of it is as simple as "please use `context` for tracking the conversation".

O_o

i wonder how many #fedidev people realize that building a fedi viewer is on the scale of complexity of building a web browser

@silverpill in any case if i had to describe "compliance levels" then it would be something like:

0: does not use context (mastodon)
1: uses non-dereferenceable context (pleroma)
2.1: context resolves to a collection representing the conversation (streams?)
2.2: context has attributedTo and participating objects are sent to this actor

so all it would take for streams to be 2.2 compliant is for their "conversation containers" to be sent to `context.attributedTo` instead of `target.attributedTo`

@silverpill i guess it does? it depends on whether comments are sent to context.attributedTo or not.

@silverpill reading through the "conversation containers" doc at https://codeberg.org/streams/streams/src/branch/release/doc/develop/en/Containers.mc i have the following comments

- the notion of a "top level post" is kinda redundant with the context, and its definition as "without inReplyTo" can be problematic if your "top-level post" is actually a reply to something. imagine an article inReplyTo something, but with its own context

- "the conversation owner (target->attributedTo)" seems to confirm not 2.2...

i will not rest until fedi devs start using as:context properly. this is my single-issue. /hj

pleroma and streams are like 80-90% of the way there, the only missing bit is signaling who owns the context via `attributedTo`

real talk tho, if you want actually existing honest-to-god threads and threading and conversations... there's a property for that!

@julian @silverpill @rimu @AaronNGray there is a tangential point here -- there is no way to signal what a collection *contains*. for example, "this is a collection of Notes" or "this is a collection of Activities" or "this is a collection of Collections" or "this is a collection of collections of collections", and so on. maybe this doesn't matter, but it could be helpful information to orient oneself...

@julian @silverpill @rimu @AaronNGray a context-of-contexts? nth-order context? you're right that there isn't really a term for "collection of collections", but that's really because the collection model inherits from ldp containers, which are basically like directories or folders. you can of course have subfolders or subdirectories. does this deserve a special term? well... maybe, maybe not.

@devnull @steve activitypub is email for websites, but what you're passing around is more than just a message. (by "activitypub" i mean the "post to inbox/outbox" bits)

bnuuy bread? fedi will love this