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 ♥️🇪🇺

  • 3 Posts
  • 129 Comments
Joined 10 months ago
cake
Cake day: August 14th, 2025

help-circle

  • It’s tough to know where to stand when it comes to AI. I don’t think anybody here is hoping that the fediverse be overrun with LLMs and bring about the dead internet theory.

    A large part of why people join the fediverse (and the threadiverse, too) is to get away from corporatization, and AI is definitely part of that too.

    I just don’t think we need to go to extremes to ban AI-generated content, but more importantly, this is not a decision that can be made globally. It must be done (and enforced, however we do that) instance by instance.




  • > @[email protected] said in A more private way to distribute votes: > > So my proposal would be: votes are only sent to the author of a post. The author then sends an Update activity to their followers and the magazine the post belongs to.

    My concern is that this goes against the implicit assumption that the group actor (the community/magazine/category) is the source of truth.

    The group actor is the clearinghouse of data in 1b12 style federation, and it would be a departure to change votes to only be sent to the target.

    Fwiw when someone upvotes on NodeBB, it gets blasted everywhere too!

    I would recommend that votes continue to be sent to group actors, who then decide whether to announce it (old behaviour) or keep quiet and wait for the update before announcing (new behaviour).

    It would mean vote synchronization would be less reliable however.

    Also this goes directly against @[email protected]’s vote batching proposal.







  • Sure. I have found that the default botPolicy works fine for blocking the AI bots, but blocks federation.

    At the reverse proxy level:

    if ($request_method = POST) {
        proxy_pass http://nodebb/; 
    }
    

    Because Anubis can’t filter by HTTP method, unless I am mistaken. This just broadly allows all incoming activities. If you want to get specific, limit it to your shared inbox or individual user inboxes via regular expression or something. I didn’t find that it was necessary.

    As for botPolicies.yaml

      # Allow /inbox
      - name: allow-ap-headers
        headers_regex:
          Accept: application/ld\+json; profile="https://www.w3.org/ns/activitystreams"
          Accept: application/activity\+json
        action: ALLOW
    
      - name: allow-assets
        path_regex: /assets
        action: ALLOW
    

    The former allows those specific AP headers (it is naive, some AP impls. send slight variations of those two headers.

    The latter allows our uploads.









  • I disagree. I think that you can have both.

    I think big tech has proven that it cannot be trusted. Their priorities are simply not in alignment with our own. Legislation seems to be the only lever that can hope to rein them in (market forces are no longer strong enough).

    At the same time, smaller networks do not have the resources to comply with government regulations to a T, and so they should be given a longer leash. Governments also do not have the resources to chase down every Tom, Dick, and Harry running a Lemmy server (well, they do, but they shouldn’t.)

    Whether reality will play out this way is uncertain.