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

@silverpill @jenniferplusplus @julian i don't understand why anyone would need to go directly from a single post to a collection of activities having to do with the thread. isn't it enough to pass through the thread itself first? e.g. take the Note.context.outbox for an "activity log", or if you're going to define a new property, then define it on the thread instead of on the post -- Note.context.history for example following https://w3id.org/fep/bad1

@silverpill @jenniferplusplus @julian

```yaml
id: x
context: thread-activities
actor: a
type: Create
object:
id: y
context: thread-posts
content: "foo"
```

thread-posts can contain your contentful objects, and thread-activities can contain everything even tangentially related to that conversation

@silverpill @jenniferplusplus @julian have you considered that maybe "posts" can have their own `context`, and "activities" can also have their own `context`?

@silverpill @julian

that's a bit simplistic imo. software doesn't matter, sure; what matters is what the software lets you *do*. but "interoperability" is not a goal in itself. it's a means to an end. for different software that let you do fundamentally different things in fundamentally different worldviews, there can be no meaningful interoperability.

example: fedi has concepts and abstractions for "posts" and "profiles". what happens when you don't have these same building blocks?

@julian @silverpill what makes something a "conversation activity" or a "post", and how are these different?

to me, a "post" is "whatever you intend for the user to see". generally this is anything that has content (or summary or name), but you can also support "contentless activities" if the semantics are clear enough. for best practices though, i'd recommend the switch-case be "presence of name/summary/content".

i don't see a reason to single out Create/Update/Like for 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

@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`