i will not rest until fedi devs start using as:context properly. this is my single-issue. /hj
-
i will not rest until fedi devs start using as:context properly. this is my single-issue. /hj
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
real talk tho, if you want actually existing honest-to-god threads and threading and conversations... there's a property for that!
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
pleroma and streams are like 80-90% of the way there, the only missing bit is signaling who owns the context via `attributedTo`
-
Erin 💽✨ @38C3replied to infinite love ⴳ on last edited by@trwnh which FEP is it again?
-
infinite love ⴳreplied to Erin 💽✨ @38C3 on last edited by
@erincandescent 7888
-
-
@[email protected] I'm only just noticing that the examples provided in 7888 don't include
to
,cc
, etc. Are they omitted for brevity, or would it be a departure from the FEP if one were to add in those properties? -
@julian brevity
-
@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.
-