NodeBB

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

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

@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.

@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...

@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.

@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

@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

@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?

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

@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.

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

> 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.

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

Hey @rimu@piefed.social thanks for responding (and sorry for the late reply!)

I am not married to the Announce([Article|Note|Page]) approach, so I am definitely open to Create([Article|Note|Page]) with a back-reference. I think I went the former direction because there is a known fallback mechanism — the Announce is treated as a share/boost/repost as normal. However, sending the Create also is fine I think.

1. However, do we need a backreference? In my limited research, it seems that Piefed, et al. picks the first Group actor and associates the post with that community. If I sent over a Create(Article) with two Group actors addressed, could Piefed associate the post with the first, and initiate a cross-post with the remaining Group actors?
2. Secondly, is how to handle sync. 1b12 relies on communities having reciprocal followers in order for two-way synchronization to be established. On my end since I know it is cross-posted I will now send 1b12 activities to cross-posted communities, but can Piefed, et al. send 1b12 activities back as well, in the absence of followers?

cc @andrew_s@piefed.social @nutomic@lemmy.ml @melroy@kbin.melroy.org @bentigorlich@gehirneimer.de

@projectmoon@forum.agnos.is basically, yes. It would be a little too involved to upend the entire system to support multiple cids per topic — a lot of our existing code relies on cid being a single value.

This would be an add-on logic of sorts, where each topic has a canonical category, but can also be cross-posted to other communities/categories.

I haven't looked into the differences between their implementation and how groups are implemented using 1b12, but what I have discovered is that the 1b12 community is much larger than I gave it credit for.

@kirkmoodey@universeodon.com yes, Mastodon compatibility is lacklustre but that's partly because the architecture of Mastodon doesn't lend itself well to categorical organization. That's not a criticism, merely a difference that we have to consider.

Currently, when a user addresses multiple communities, then the existing software (NodeBB included) uses the first one. How the rest of the addressed communities are handled is what's of interest here.

@ludrol@szmer.info yes, you're right about that. The silver lining here is that we're at a point where the major players' implementations are local-only, so we don't have to work around with a pre-existing implementation and ensure compatibility.

The second point is that a "cross-post" could have multiple meanings, including manually creating a new post about a link already present in multiple communities. What I'm hoping to describe is a common way that items can be cross-posted natively between instances, while hopefully preserving their reply-trees.

Following up on this question I asked back in late March, I wanted to continue thinking about how one would handle cross-posting between categories/communities, given that there isn't current consensus on it, and especially given that NodeBB—as of v4.3.0—can now see and browse remote categories.

From that original topic, we can distil the following:

1. Both PieFed and Mbin do not natively handle cross-posts, a new entity is made with the crucial bits (link, text, possibly title) copied over and changed if needed, sometimes a "cross-posted from..." helper text is prepended.
2. There are legitimate concerns that a cross-post might not succeed depending on privilege settings on the receiving end, so a pre-flight check (or explicit rejection) of some kind might be required.
3. Cross-posting can be done by the original author, or another user.

So were an FEP to be written, we'd center it around the following assumptions:

• "A user (which may or may not be the object author) is sharing an object to additional audiences"
• We would use the existing Announce(Object) model
• We would not use Announce(Activity) because it is not the original object creation that is being announced, but the object itself, to a new audience.
• Some form of Reject handling would be required for cases where the cross-post is not allowed
• How the receiver handles the activity is out-of-scope of the FEP. It could be that the original object is contained within multiple categories/communities, or a duplicate object could be created — implementor's choice.

This is very similar to an existing announce/boost/reshare, except that instead of addressing the activity to followers list you are addressing it to a group actor's inbox.

Some additional questions:

1. Is there desire from PieFed/Lemmy/Mbin for supporting incoming (and possibly outgoing) federation of cross-posting?
2. What exactly happens currently if a Group actor receives an Announce(Object)? My guess is nothing, currently, but let me know otherwise <img class="not-responsive emoji" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f604.png?v=aafd56e36a3" title="" />
3. Would this allow you to accept cross-posts from other AP applications without needing to refactor any existing code?
4. Duplicating the object would mean the discussion is split between objects. The ideal implementation would be the same object present in multiple categories/communities. Is there desire for this in the threadiverse?

@rimu@piefed.social @andrew_s@piefed.social @melroy@kbin.melroy.org @bentigorlich@gehirneimer.de @nutomic@lemmy.ml @angusmcleod@mastodon.social

@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.