@jwildeboer@social.wildeboer.net Right, there's a possible social engineering vector at play here, which I think makes this a little concerning. I certainly don't like my time wasted either cc @thisismissem@hachyderm.io @mariusor@metalhead.club

@osma@mas.to the default assumption is that announces are delivered back to the origin server in order to close the loop. However it is not a requirement. For example I am considering not doing so for group announces.

@shoppingtonz@mastodon.social if edits from PieFed aren't reflected here that may be a bug.

@naturzukunft@mastodon.social that's what I plan to do at least at a smaller scale with FEPs that deal with threaded conversations

@silverpill@mitra.social when discussed with Nutomic about this, I made the case that 1b12 is excellent for synchronization. 7888 (and 171b, etc.) are good for backfill, in cases where there is no 1b12 implementation available.

@squinky@teh.entar.net in all seriousness it's entirely up to you which FEPs to support. Some FEPs have more adoption than others, so it would be wise to adopt them over time as well. Others deal with aspects of the protocol that may not even apply to your specific use case. There is no expectation that one should implement every FEP. Think of it this way: an FEP is a way to document in public (not in code!) how one or more implementations have approached a problem that the ActivityPub protocol spec did not cover. There may be a lot of them, they may be needlessly complicated, but it's better than having to dig through someone else's code base.

NodeBB is gearing up for a major release this month that brings full two way federation and content discoverability to forums as well! We've been working on it all last year! @activitypub