Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

NodeBB

julian@community.nodebb.orgJ

julian@community.nodebb.org

@julian@community.nodebb.org
Unfollow Follow
About
Posts
41
Topics
3
Shares
0
Groups
0
Followers
0
Following
0

View Original

Posts

Recent Best Controversial

  • Following a Lemmy community doesn't bring in new posts (v4.14.2)
    julian@community.nodebb.orgJ julian@community.nodebb.org

    In general, moving topics between remote categories is disallowed because it's misrepresentation. You're limited to moving uncategorized topics to a local cid, topics between local cids (of course), and cross-posting topics to local categories.

    There are some gaps in federation, as @informapirata states. I've been actively working toward finding and closing those gaps.

    @informapirata @sj_zero@lotide.fbxl.net @kichae@wanderingadventure.party

    ActivityPub

  • Following a Lemmy community doesn't bring in new posts (v4.14.2)
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @informapirata indeed, I fixed a number of federation issues between NodeBB and Lemmy, in v4.14.0, and again since. I'd recommend updating to the latest stable version and running those federation tests again.

    ActivityPub

  • NodeBB 4.13: activitypub/fetchPublicKey Rate limit exceeded errors.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @Kichae hmm if there was a rendering issue on their end it could be either end (sender or receiver). Can you share the post?

    Bug Reports

  • NodeBB 4.13: activitypub/fetchPublicKey Rate limit exceeded errors.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    https://github.com/NodeBB/NodeBB/issues/14422 for updates.

    Bug Reports

  • NodeBB 4.13: activitypub/fetchPublicKey Rate limit exceeded errors.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @Kichae there's definitely a federation issue with Lemmy here...

    This dashboard shows ActivityPub.Space is just over three weeks behind lemmy.world. Failure count is ~64, which means Lemmy stopped sending stuff over.

    I upped my public key fetch limiter value to 512 as well, and will see if this addresses the issue.

    Bug Reports

  • NodeBB 4.13: activitypub/fetchPublicKey Rate limit exceeded errors.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @Kichae understood, I'll have to take a closer look.

    There is definitely an issue, some relays have stopped working but I'm sure the relay is fine.

    Stay tuned...

    Bug Reports

  • NodeBB 4.13: activitypub/fetchPublicKey Rate limit exceeded errors.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @Kichae Lemmy may take a little while longer because there's a cooloff period they won't send content until your server begins responding again.

    The IP limit rejections caused those Lemmy servers to temporarily mark yours as down. Lemmy queues everything for later delivery.

    Bug Reports

  • NodeBB 4.13: activitypub/fetchPublicKey Rate limit exceeded errors.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @Kichae hmm, perhaps the fetchPublicKey IP limiter isn't bit too aggressive.

    https://github.com/NodeBB/NodeBB/blob/81124e40c714c80c5509a510ca0d1de1367c8d3f/src/activitypub/index.js#L242

    See if you can modify this line. Try changing 60 to something higher like 180 😐

    Bug Reports

  • NodeBB 4.13: activitypub/fetchPublicKey Rate limit exceeded errors.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @Kichae are the IP addresses ones you control? It may be triggering the rate limit when the incorrect IP address is proxied in.

    I experienced this too, and it was due to Anubis not passing the right IP through. I just disabled it for now <img class="not-responsive emoji" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/customizations/6854442b-3161-4485-a9c4-ea0977c622e7-abf762c960d25b9d.gif?v=32e548a362d" title=":think:" />

    Does that sound like something similar? The rate limiting was added to guard against unchecked use of the affected endpoint

    Bug Reports

  • 🎟️ Today is the last day to get DISCOUNTED EARLY BIRD tickets for FediCon 2026 — don't miss your chance to grab a discounted pass!
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @reiver@mastodon.social thanks, and if I'm presenting (which is up to you I think!) do I have to buy a ticket to FOSSY too?

    Technical Discussion fedicon fedicon2026 fossy fossy2026 fedidev

  • 🎟️ Today is the last day to get DISCOUNTED EARLY BIRD tickets for FediCon 2026 — don't miss your chance to grab a discounted pass!
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @fedicon@techhub.social I still don't understand which two days are FediCon?

    Technical Discussion fedicon fedicon2026 fossy fossy2026 fedidev

  • FEP 11dd: Context Ownership and Inheritance
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @trwnh@mastodon.social Yes you're right, some messiness is bound to happen.

    I'm not trying to force all implementations into a specific inheritance pattern, that's why it's a "should", not a "must".

    Even then one of my concerns is that while in an ideal scenario, everybody inheriting their parent context leads to an entire collection all referencing the same context... in reality a lot of messiness will occur, objects will reference other contexts all over the place, etc.

    At the end of the day it's best effort, and if we are able to handle all that and still get to a point where backfill is achievable, then that's a win in my books.

    > it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)

    Part of me would like this to not happen, but it is unavoidable.

    Technical Discussion fep activitypub

  • FEP 11dd: Context Ownership and Inheritance
    julian@community.nodebb.orgJ julian@community.nodebb.org

    Good question — in my opinion, 7888 serves as a gentle introduction into the entire concept of conversational contexts. It's meant to be descriptive in order to capture the variety of existing implementations of context that are found in the wild (e.g. Pleroma context which doesn't resolve, contexts that are not URLs, etc.)

    Each subsequent FEP "down the tree" (or up, depending on how you look at it) narrows the scope and upgrades verbiage in order to enable additional functionality.

    Specifically pertaining to 11dd:

    • Ownership is explicitly defined and is now a requirement, 7888 mentioned attributedTo and context ownership as examples only.
      • This upgrade was done to set the stage for subsequent FEPs for forking, merging, moving, etc.
    • Activities should be sent to the context owner. This is identical to 7888, but re-stated as a reminder.
    • A specific recommendation for inheritance is included (adopt the immediate parent's context, more if able), while 7888 allows for one to drop context altogether, inherit, or create your own.

    This is not to say that 7888 is deficient in any manner. On the contrary, it's working entirely as intended!

    In practice, Lemmy has adopted 7888, but at this time will not adopt 11dd. @nutomic@lemmy.ml creates a context local to the instance, for each post because each instance is expected to be the canonical representation of the context, even if they are cached representations of remote federated content.

    It means it would preclude Lemmy from adopting further upgrades like forking/merging/moving/locking, but it doesn't mean they are wrong in doing so.

    @trwnh@mastodon.social

    Technical Discussion fep activitypub

  • FEP 11dd: Context Ownership and Inheritance
    julian@community.nodebb.orgJ julian@community.nodebb.org

    > I don't quite understand what "its own context" means here.

    This line was lifted from an earlier draft where additional examples of defining ones own context, removing a context, or inheriting a context, is spelled out explicitly.

    I realized after drafting that that was already more or less described in 7888 and so brevity won out.

    I will need to reword that.

    Technical Discussion fep activitypub

  • APx is finally available on crates.io / docs.rs
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @silverpill@mitra.social nice job! Congratulations on the release 🙂 now you must maintain it for free forever.

    General Discussion activitypub rust apx

  • @naturzukunft@mastodon.social > rdf-pub.org is providing c2s
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @trwnh@mastodon.social but why must a separate account be made? Account fragmentation is yet another unsolved problem because the new user on account B is functionally useless: no followers, etc. and the content isn't automatically available to the followers of the user on instance A.

    General Discussion activitypub c2s

  • @naturzukunft@mastodon.social > rdf-pub.org is providing c2s
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @trwnh@mastodon.social the idea behind B delegating actions for A to carry out is that A is the actual owner of the user, and can sign it accordingly (per same origin security)

    There are object proofs but those aren't exactly easy to implement...

    General Discussion activitypub c2s

  • @naturzukunft@mastodon.social > rdf-pub.org is providing c2s
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @strypey@mastodon.nzoss.nz fwiw I'm thinking that C2S might be applicable in an S2S-like setting where a user "logs in" to instance B using instance A's credentials, and B can do limited actions as the user on A. Essentially A would act as the server, B is the "client".

    General Discussion activitypub c2s

  • How to subscribe to a thread?
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @silverpill@mitra.social I think given the addressing limitations of collections, this by-proxy method of determining who to send an as:Follow to makes sense as a stopgap measure until ActivityPub's next version...

    General Discussion activitypub fep

  • EDIT: Turns out my initial assumptions were entirely incorrect.
    julian@community.nodebb.orgJ julian@community.nodebb.org

    @hexaheximal@mastodon.social that's fair. I also feel a certain responsibility to protect and defend the fediverse from bad actors, so I get being on guard.

    I've also seen what happens when fedi brings out the pitchforks, though 😬

    General Discussion fediverse activitypub frequency frequencyapp
  • Login

  • Don't have an account? Register

  • Login or register to search.
Powered by NodeBB Contributors
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups