Co-Founder (NodeBB) | Husband 🤷‍♂️ and Dad 🙉 to three | Rock Climber 🧗‍♂️ | Foodie 🥙 | Conductor 🎵 | Saxophonist 🎷

✅ Small teams craft better code.
🗨️ Federating NodeBB (in-progress) with funding NLNet ♥️🇪🇺

  • 18 Posts
  • 14 Comments
Joined 11 years ago
cake
Cake day: June 17th, 2013

help-circle




  • Hi @scott@authorship.studio, thanks for your thoughts. I took the evening to think it over.

    I agree that using thr:thread would be the most explicit way of signalling that NodeBB topics are threads, and if 76ea were to be adopted by a majority of implementors, then I would reconsider. Currently I am on the fence about whether or not I should implement it.

    I do want to point out that @trwnh@mastodon.social’s FEP 7888 doesn’t expressly forbid multiple contexts, and I think upthread they even said that such a use case would not be contrary to the FEP:

    based on this conversation i probably need to add examples to fep-7888 of how one might process multiple contexts. ~ trwnh

    My opinion today is that when NodeBB uses context, it is doing so to signal that “hey, these posts are part of this collection”, and exactly nothing more. It is up to the receiving end to decide how to implement it, and I think that this sort of variety is absolutely wonderful.

    If, for example, someone were to see my context and say “I’d like to map this context’s objects out into a word cloud and do sentiment analysis on it”, I think that’s a perfectly cromulent use of the data. For me to say “this here is a thread, and you better treat it as a thread” is contrary to the spirit of ActivityPub and fedidevs in general.

    It would be like the ForumWG saying to Eugen, @renchap@oisaur.com, et al. that “we’ve decided that YOU, Mastodon, need to support as:Listen and render inline players, and playlist support, etc.”. That’s ridiculous, wouldn’t you agree?











  • This also reminds me of a discussion I had way back when I first joined fedi, with @leroy@indiehackers.social . When mocking up a forum-like frontend for ActivityPub data*, he actually rendered the content of the inReplyTo as a blockquote before the reply, which is actually quite an interesting use-case for inReplyTo!

    * Also, is there anything more indie hacker than that? lol