i will not rest until fedi devs start using as:context properly. this is my single-issue. /hj
-
@julian more specifically, the examples use `audience` instead of to/cc, but you can use any of the three (to/cc/audience)
-
@[email protected] there's nothing specific in these two Notes that set them apart from any other note that was properly processed. I also don't have logs from that far back (because I was travelling last two days, sadly!)
If it happens again, please let me know and I'll take a closer look.
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh you mean, a real `Collection` that contains all the objects in that conversation?
-
infinite love ⴳreplied to Evan Prodromou on last edited by
-
infinite love ⴳreplied to Evan Prodromou on last edited by
@evan that would be the ideal, yes. streams does this (except i think they expose all the activities). pleroma uses a uri that doesnt resolve to anything. mastodon still uses the old ostatus:conversation.
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh 🫤 we'll get there. Is there a FEP?
-
@trwnh interesting, I thought about this and decided that context should not be derefencable because nobody owns it. Anyone can create a new context, and then anyone can append to it. If you want to own the collection, make it a proper replies collection.
-
@tedu the problem with deferring to a "replies" collection is that declaring a context is completely orthogonal to declaring a reply
my thinking is that IF:
- the context is present
- the context is dereferenceable
- the context is a Collection that has attributedToTHEN:
- the context collection is managed by that attributedTo actor, via Add/Remove
- you can participate by sending your Create to that actor, with the object having the same context -
infinite love ⴳreplied to infinite love ⴳ on last edited by
@tedu side note, you do run into similar issues with establishing a two-way confirmation, e.g. that a reply is in the replies collection, or that an object is in its declared context. but that's a matter of convention and not a technical issue. i suppose you could have reply proofs and/or context proofs, but that's out of scope and is an exercise left to the reader
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@tedu my tentative approach would be to have a resolvable "stamp" in the form of an Add activity targeting either the `replies` collection or the `context` collection, although one raised objection was that fedi devs don't want to check for inReplyTo.replies being equivalent to replyProof.target? i can't say i understand the objection myself... something about inefficiencies with current database schemas in Mastodon et al. the alternative proposal was a custom AcceptReply activity, i think.
-
-
@trwnh Conversations in streams now have attributedTo property (example: https://fediversity.site/conversation/7342c8d7-6ac2-4128-8168-6cbd0dc9a37c). Does it make streams a complete FEP-7888 implementation?
-
@silverpill i guess it does? it depends on whether comments are sent to context.attributedTo or not.
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@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 actorso 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`
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@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...
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@silverpill cc @mikedev for posterity. also the swicg threaded discussions task force (hi @julian and @angus) is looking at this from a forum perspective and not just a social media perspective. it is quite likely they will arrive at a similar finding in their report
-
@[email protected] something @[email protected] and I were discussing was that some implementations include OP in the Page/context (iirc Lemmy does this @[email protected]), and subsequent replies are Notes, whereas NodeBB, Discourse, and later Flarum, treat the context as merely a container.
It seems the latter fits better with the vision of 7888 but I'm not sure whether concessions need to be made for those other types.
