Erin 💽✨

@evan @julian @silverpill @trwnh @mikedev “context” isn’t good enough to identify any relationship; this is the fundamental problem. It is a property that should never have existed. Today it identifies one relationship: the (loosely defined) thread. I would argue that this is in fact “common interoperability”. I would also argue that this fully meets the incredibly vague letter of the ActivityStreams specification.

I have yet to see an alternative use of context that would not be better served by inventing a more specific term. Yes, this applies to use of context for thread too, but we have 7 years of its user to identify the thread as a defacto standard.

@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected]

My plan is to bring Akkoma into conformance with FEP-7888. Contexts (as they implicitly exist) contain Objects in Akkoma today, and my plan is to make that collection dereferencable.

At the moment I have no plan to implement sending of Add activities though that could come in the future.

Regarding FEP-171B’s use of the Context object type, I am ambivalent. We will likely expose an (Ordered?) collection at first.

FEP-76EA’s definition of thr:thread doesn’t match how Akkoma maintains or interprets the Context today. My opinion is that I would only invest time in implementing it if implemetations actually coalesced around it; it doesn’t suit our needs. In particular the requirement “The tree structure of the thread should be maintained; every object in the thread collection, except the root, should have an inReplyTo property that matches the id of another object in the collection.” does not match how Akkoma handles quote posts (it places them in the same Context).

@evan @julian @darius Would the same line of argumentation not apply for “Why is this a new FEP and not an issue raised against FEP-7888?”

@evan @julian @darius I don’t really have a horse in this race but we’ll probably never get rid of the existing use of context so I mostly question the advantage of us having to deal with three conversation grouping properties for the indefinite future

@evan @julian @darius That doesn’t really cover the why other than “context is vaguely defined” (maybe, but its’ been used in this exact way for… 7 years now? And is being used in this way by multiple interoperating implementations)

@julian @trwnh (Well, I guess whether it resolves or not is a matter of semantics. Arguably it resolves… just, it resolves to a 404)

@julian @trwnh When Akkoma originates a thread the context it populates it with doesn’t resolve.

However, fixing that is on my plate.

@darius @evan @julian side note: Akkoma also emits a “conversation” property containing the same URL, which is JSON-LD mapped tohttp://ostatus.org#conversation. This is because Mastodon will pass-through the conversation property to replies, but doesn’t know about context. When Mastodon generates a Conversation tag (e.g. when its absent from the parent post), it stuffs a tag URI like tag:cosocial.ca,2024-10-04:objectId=26829720:objectType=Conversation into it. This is visible in evan’s earlier post

side side note: “conversation” is misdeclared as a “@value” and not “@id” property in Mastodon’s context. Oh well.

@[email protected] @[email protected] @[email protected]

curl -H "Accept: application/ld+json" https://akko.erincandescent.net/objects/6d40d43e-9929-4bf9-9a9b-725ef3a682cd | jq

{
  ...
  "context": "https://community.nodebb.org/topic/18328",
  "id": "https://akko.erincandescent.net/objects/6d40d43e-9929-4bf9-9a9b-725ef3a682cd",
  "inReplyTo": "https://cosocial.ca/users/evan/statuses/113250578296473665",

@evan @julian @darius How does the “thread” property differ from the “context” property which basically every implementer is already using and has been doing so for 6+ years?