@ernest I see you posting more and more about community management and server/service maintenance than coding on the project.

How do you deal with doing both: a maintainer for a project and a community manager ?

I was trying to push people interested in #BrutaLinks in starting their own instances instead of using mine, and seeing how nobody took me up on that, it feels like it's the losing strategy. :D

@plactagonic I've never ridden a recumbent, so I want to ask what's the problem? Not enough gears for pushing uphill at a comfortable power/cadence, or keeping balance?

@bicycle_touring

@MeowerMisfit817 hey, I didn't know anyone was looking at the website, so I didn't prioritize fixing it.

I'm having issues with SSL certificates at the moment, that's why it's in maintenance mode. I'll see what I can do.

@julian my perspective is that the fep is addressing _only_ server to server logic. From a client to server perspective, you're building the context ordered collection out of thin air (ie, no Create for it), which is not conducive to good consistency between nodes. Additionally that collection is not needed because it already exists in the form of the /replies collection of the top post. If you would use that a context, I'd feel better about it. (I use(d) a similar method in brutalinks - but I had the top level comment itself as a context, not the /replies directly.)

@julian see my caveat in one of the replies above:

> Caveat, this requires that all replies to a post, include in their inReplyTo property at least their parent and the top post - ideally they should include the whole chain of parents to the top post.

(Also, when I said "overcomplicated" I really meant, "possible in the framework of what current vanilla ActivityPub provides, _without_ needing extra operations or concepts", the idea is simple enough, and sound at its core: a container where all replies can be found.)

@MeowerMisfit817 OK, it's back up now. Thank you for your interest. :)

Let me know if you have any questions.

@silverpill I think you're saying this from a position where identifiers in ActivityPub are no longer unique URLs and therefore "canonical representations" are harder to reason about, but in my opinion that's not where the protocol is now, and hopefully, not also in the future. And yes, I am aware of context, I am pretty sure I have one the first implementations that made use of it as a thread container, but that whole fep is over engineered and IMHO missed what I consider the obvious and simpler solution: put all parents in the inReplyTo and include all parents' authors as recipients. 🤷

@technical-discussion @heluecht @julian

@silverpill sorry if I misunderstood :( I was under the impression that you're working towards embracing DIDs as identifiers as far as I remember. To my mind that moves away from "you get the canonical representation of an object by fetching the URL of its ID" to any representation of the object that passes identity proofs. (perhaps I'm wrong in thinking this anyway, my investigation on how DIDs relate to canonical object representation was cursory and incidental) That's what I meant.

@technical-discussion @heluecht @julian

@julian sorry, but what are "indirect replies". My imagination fails me, or I haven't read the fep with enough attention.

@silverpill sorry to butt in, but all of this would be solved by respecting what the canonical representation of a reply thread is: the replies collection of the top post[1]. I think it makes much more sense to built that correctly and rely on it instead of trying to keep all the nodes of the network in sync with countless activities.

[1] Caveat, this requires that all replies to a post, include in their inReplyTo property at least their parent and the top post - ideally they should include the whole chain of parents to the top post.

@heluecht @technical-discussion @julian

@evanprodromou is this overlapping or alongside the work done by @soatok ?

https://soatok.blog/2025/12/15/announcing-key-transparency-fediverse/

@evanprodromou probably it's not entirely useful, as this is my first attempt at building web components, but I've done similar work for one of my projects: https://git.sr.ht//~mariusor/oni/tree/master/item/src/js

They are not zero dependency however, they are built with the help of lit.js.

@jessel what does "support groups natively" mean to you ?

There are Group objects in the ActivityPub vocabulary already.

Posting to a group is already covered by well trodden interactions.

With a little charity with regards to the interpretation of some other vocabulary activities we can say that joining/leaving a group are also there.

What more do you think is needed?