Evan Prodromou

@julian @silverpill no recos for consumers yet, but: I’d start with content negotiation, then Link headers. From there, fallback to <link> elements in HTML. Last recourse, try Webfinger, especially for non-HTML resources like images.

@julian @silverpill the HTML discovery tf doc is filling in. There’s still a lot to do but maybe that’s a good place to ask questions.

https://swicg.github.io/activitypub-html-discovery/

@erincandescent @julian @mikedev @silverpill @trwnh we have many orders of magnitude more AS2 objects in our future than in our past. I don’t think informal practices of existing software should keep us from implementing better formal systems in the future.

@erincandescent @julian @mikedev @silverpill @trwnh there are other uses called out in the AV spec. Someone using those would clash with the use for threads.

I recognize your aversion to change, but “don’t change anything” isn’t on the menu. We need a way to identify the thread relationship, and a dedicated property is much better than a duck-typing objects or making a new object type.

@julian @silverpill @trwnh @erincandescent @mikedev I think context can be used as a fallback, which provides continuity for most of the legacy implementations.

@julian @silverpill @trwnh @erincandescent @mikedev I think most developers understand that the reply tree and the conversation are identical. The use cases a describes – forking, etc. – can be implemented with Announce, perhaps with content in the Announce activity. I’ll add these next week and push a new draft.

@julian @silverpill @trwnh @erincandescent @mikedev @[email protected] obviously context isn’t good enough to identify the thread relationship. Trying to hijack it is contrary to the AS2 spec and common interoperability. One proposal tries to specify it by duck-typing every object; the other by defining a new Collection type. The clearest way to define the relationship is with a property, thread, which is specific, clear, and requires no other changes.

@[email protected] @theverge so, a direct benefit to consumer choice. It’s a win!

@deadsuperhero @julian @darius

1. It defines a new property, thread, to identify the conversation thread of an object, instead of the context property, which can be used for other things besides threading.
2. It uses an existing type, OrderedCollection, for the thread, instead of creating a new type.
3. It defines a root property to quickly navigate from a thread collection to the root object.
4. The thread contains objects that point to each other using the inReplyTo property.

@silverpill @darius @julian thank you!

@erincandescent @julian @darius I think the best followup might be commenting on the PR or filing an issue on Codeberg.

@erincandescent @julian @darius finally, if you’d like to talk to me as part of the Threads TF or even as part of the FEP process, where there’s a code of conduct, I’d appreciate it if you dial back your derisive tone. It’s not OK to talk to me or anybody else working on AP that way.

@erincandescent @julian @darius great. You can definitely use both.

context is fine for any kind of grouping of objects, as is noted in AV.

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-context

If you want to specifically talk about a conversation tree, a more specific property is better.

@erincandescent @julian @darius you can also file an issue here:

https://codeberg.org/evanp/fep/issues

@erincandescent @julian @darius it’s covered in the doc, which is free to read!

@julian @darius I started a new FEP to define a vocabulary specifically for threads.

https://codeberg.org/fediverse/fep/pulls/406

@wisdomchicken it’s funny that it seems like magic, since we’re all on the same Internet. We’ve been conditioned to have such low expectations!

@wisdomchicken @Hazzard absolutely! Hazzard, I’d love to discuss!