Skip Navigation

Posts
12
Comments
159
Joined
7 mo. ago

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

✅ Small teams craft better code.🇨🇦 Made in Canada🗨️ Federating NodeBB with funding from NLNet ♥️🇪🇺

  • To my knowledge, one must be an "invited expert" in order to join these discussions.

    However, the working group is only one aspect. The community group has been in existence for a number of years. I am part of that group (although I admit I don't go to as many meetings as I ought to), and try to represent the threadiverse as best as I can.

  • Nope, it's just a.single route, no filters or qualifiers I am aware of.

    One could go through the returned accounts and see which are users and which are groups, although that's expensive and time consuming to do.

  • By the time it (unique handles between users and categories) was needed, NodeBB had been around for 10 years and installed in countless places.

    It needed to be done in one fell swoop so we coded an upgrade script that prioritized the user slug (as historically it had been around longer).

    Hopefully the only thing you really have to federate out is an Update, but who knows what'll happen.

  • Agreed... I didn't respond right away since I wasn't sure if I was right, but there are two constraints at play here:

    • Lemmy wants to allow communities to be named the same as a user
    • This is not allowed in webfinger (insomuch that multiple IDs reports should refer to the same entity)

    You can fault Mastodon for not handling it, but I think the onus is on Lemmy to adjust their behaviour.

    For reference, the same constraint happened with NodeBB. When we started, categories didn't have handles and were not unique with users (so, a category could be named the same as a user). I needed to make the handle unique between both categories and users, for this exact reason.

  • Oh hey, thanks! You saved me from needing to crosspost it here :laughing:

    ... which... is frickin' ironic, isn't it, because we aren't at the point where we can crosspost between instances yet...

  • Thanks for sharing, that's quite exciting. I'm assuming BlueSky users can post to Lemmy instances (like other threadiverse) instances by mentioning the group actor?

  • Last I heard the Forkiverse instance has over 2k members! All the power to them :smile:

  • Happy to take a look in the AM, it's nearly midnight here. I'm confident I'll be able to figure out why NodeBB can't load your emoji at least.

    As for mine, the emoji itself is transmitted with the activity. It's just how Mastodon does it so I mimicked their implementation.

  • No, not yet :frowning: I wonder why. I'm using one in this post so I can compare...

    No clue! They look the same! Mine has an id, but I don't think that'd make a difference...

  • @rimu@piefed.social oh... No I cannot 😔 but we shall figure it out!

    Edit: ah you're missing a tag entry with type Emoji. Check out the AP data on my reply to see it.

    In the rendered HTML you actually don't render the image, it usually gets stripped for safety

  • Yes, let's talk about how that would work.

    It has much to do with my cross-posting FEP which I have... not written. It is largely in my head at the moment 😢

    Can Piefed see my emoji now? 😬

  • Done! Thank you for sharing, and thank you even more for including NodeBB in the questions!

    We're probably a rounding error at present 😝

  • @die4ever@thefedi.forum hi from another NodeBB! (god this will never get old)

    NodeBB maintainer here. Glad to hear you're enjoying the software! I really tried to make it so that federation is rather seamless. There's a lot of work to be done with respect to discovery, so it'll only get better over time 🙂

  • Sounds like Rakuten actually...

  • Hey @approxinfinity@community.nodebb.org! Long time no see :smiley:

    You guys will always have a special place in our hearts, because you were one of the very first people who put their trust in NodeBB.

    Waaaaayyyy back when we were a scrappy little forum project run by a couple of guys, you trusted NodeBB to power your forum. I think that probably makes kubuckets.com one of the oldest NodeBB forums still running (although I think community.nodebb.org probably beats you by a bit)!

    That you've discovered ActivityPub on your own and found the NodeBB connection is just great :smile: we're around as always to give you a hand!

  • @silverpill@mitra.social said in Minutes from 4 December 2025 WG Meeting: > It's not possible to sign a dynamic object, because some of its properties are constantly changing (items, totalItems and others). This means collections need to be always server-managed. Therefore, clients shouldn't be allowed to directly create, update or delete them.

    Mmm, signing doesn't guarantee data correctness, it only guarantees that the data presented is correct as of sending, per the sender's point of view.

    Just like how signing a Create(Note) only guarantees that the note's data is what it is at the time of the Create, a Move(Context) only guarantees the validity of the context's data at the time of the Move.

    That said, this FEP doesn't have you including the entire object in, just the URI, so this is moot........ no?

  • Sorry it took so long to respond to this —

    Re: assumption of a context belonging to one audience > Where, in Lemmy? Even if some implementations don't support cross-posting I don't see a reason to block it at the protocol level.

    This FEP doesn't block cross-posting at the protocol level. Move just explicitly states that a context was Removed from one and Added to another. You could achieve this just fine with Remove followed by Add, but this just reduces it down to a single activity and eliminates any side-effects (e.g. a Remove without corresponding Add might mean content is purged from the db)

    So in theory, a context can belong to multiple audiences, and it can be moved from one to another, or removed from one.

  • > If it's some automated feature, I don't think it should be in the source property of the federated JSON in the first place.

    Thanks, it's this.

    Edit: oh interesting, I looked into it. We serve the absolute URL in HTML but not in markdown. I had no idea threadiverse apps read the markdown. Neat!