@pfefferle@mastodon.social I'm frankly surprised I ran into a side effect of this so soon after you updated the site <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f606.png?v=dc334ca9dcb" title="" /> Either the PR is to be reverted or perhaps WP should handle requests to the URL encoded address <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f937.png?v=dc334ca9dcb" title="" /> But after briefing myself on the root cause, it does seem weird that there exist actors with unicode in their ID. Might be if that is the case you should disregard them as non-compliant, who knows. cc @silverpill@mitra.social

@julian The ActivityPub API Task Force has a meeting today at 11AM EST. https://meet.jit.si/activitypub-api

@js@podcastindex.social thanks!

I've seen hints of backfill working really well, but hadn't seen good examples until recently. As more and more instances upgrade to the newer versions of Mastodon that support context, backfill from Mastodon instances will improve across the board. Today one of the most popular topics on my NodeBB instance was an update from the admin of The Forkiverse, a brand new up-and-coming instance. Despite following only one person from that instance, I was able to see every single reply from that instance, even from users I don't follow. Super stoked to see resolvable contexts and backfill working in the wild. Who says the Fediverse is quiet? Not me, anymore

What is so difficult about comparing a cached object with a new object when handling Update?Move and Remove are just as broad, and these are activities for manipulating collection items. I guess they work well for you because you don't use them for anything else.

@thisismissem said in ActivityPub API Client Reputation: > Client reputation isn't really something you can track and share in a decentralized network without introducing some centralisation. I think that some centralisation is fine, as long as admins or even users can choose their reputation data provider. We do this with blocklists for instances already; there's no reason to think that client blocklists would need to be any different. They'd have to have the same caveats; a trusted provider, transparency in the process, etc. > You'd also need moderation tools that can moderate clients in some sort of meaningful way — that's near impossible for dynamic client registration. Agreed. The best I can think of is using the redirect_uri, but that's not really unique -- especially for command-line clients that use localhost! I think the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal. I think it'd be a similar issue for ActivityPub API clients. > That's why we wrote the CIMD spec. Yes! Using the same identifier for clients in a verifiable way is a big help in having a reputation for using on a single server or multiple servers. > But OAuth security and trust models are complex and generally proprietary I think you could get to some pretty useful metrics pretty quickly, though. Some good ones to use might be: How many people on this server (or other servers) have authorized the client What the average rating has been (but you need a way to rate clients!) How many Flag activities have been submitted for this client (you need a way to report clients) Reviews of the client (you need a way to write a review of a client) That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.

@julian@fietkau.social that's a great idea! I should adopt that, there's no downside.

"Critical concept: IRIs are opaque identifiers. You cannot infer meaning from the string pattern — only by dereferencing and inspecting the data." [1] This applies to URIs too. Sadly, almost no #ActivityPub implementations use this principle. Multi-tenant servers and simple account portability (with personal domains) would be relatively easy if they did. It is what it is.../cc @melvincarvalho [1] https://socialdocs.org/docs/concepts/uris-iris-linked-data/

@pfefferle in the admin panel!

@heathenstorm right, so Pixelfed isn't responding to your configuration change (which no one else will know about unless you explicitly tell them)I recall Pixelfed had some command to clear its cache of config, it's in like the CLI commands section of the docs.

NodeBB federates out the Announce activity in two ways. The "plain object" way, which is an Announce activity wrapping an object (either a uri or the full object itself.) The "1b12" way, which is an Announce activity wrapping another activity (e.g. Create) Up until now I haven't needed to handle the reverse (which in AP-speak is the "undo" of an activity), but since NodeBB sends Announce when moving a topic in to category, it now makes sense to Undo(Announce) when moving a topic out of a category. My first interop test with Mastodon didn't work, and it turns out that Mastodon checks the id of the embedded Announce for a match. It doesn't infer it based on actor/object combination. Once I matched up the IDs, the Undo was processed correctly. I also noticed that Announces sent from Mastodon have a published property, although this is not relevant in Undo parsing.

@silverpill only an actor that owns the collection can operate on it, and only the server that resides on the same host can operate on collections with that host. Ie, all the logic I'm describing refers to client to server, collections that reside on other servers are not really relevant. And I don't know if I mentioned it before, mostly GoActivityPub focuses on the vanilla specification, the fancy use-cases in FEPs, like nomadic identity, are outside the scope until we can make use dynamic object types - which is not the case at the moment, we're limited to plain Activity vocabulary.

@derickr a bit more detail at https://shkspr.mobi/blog/2025/10/getting-started-with-mastodons-quote-posts-technical-implementation-details-for-servers/

@OpinionatedGeek @kopper It looks like the proxy end point is indeed what I want. I added a ticket for implementing that, because currently proxyUrl is not supported by #GoActivityPub. https://todo.sr.ht/~mariusor/go-activitypub/409

@mariusor I agree that finding those last percents of coverage can be a pain.But yes, more so trying to get a full app coverage up is hard and unsatisfactory work.

What if we could federate over git?! Check out my latest post #fediverse #git

@silverpill @helge@mymath.rocks @helge@mastodon.social @julian can y'all copy me out — I just CC'd Julian as lead on forums taskforce, I don't personally care that much

@bob I federate with onion and i2p instances and I haven't noticed any issues. The worst thing that could happen is that reply on server A to an i2p post will be displayed as a top-level post on server B.You can try with http://mastodon.i2p

Thank you so much!

Showing off the first deployment of the FIRES reference server to a few people I've just landed dataset exports, for getting a zip file snapshot of a dataset with files for domain denylists/allowlists, and a retractions file. The denylist / allowlist should be compatible with the Mastodon Domain CSV files, but unfortunately @Mastodon doesn't support importing a retractions file.