silverpill

https://datatracker.ietf.org/doc/draft-newbold-atp-aturi/01/

This document defines the "at" identifier scheme, which is used to reference accounts and data records in the Authenticated Transfer Protocol.

My instance was offline for several days. If you sent me anything during that period, there is a good chance it was lost.

New DID method: did:vh

This is a generalized variant of did:webvh, without strong dependency on web & http.

Seems to be a good fit for FEP-ef61, I added this method to the list of candidates: https://codeberg.org/fediverse/fep/pulls/952/files

#fep_ef61

I said before that Accept should never be used outside of Follow interactions. Want to "accept" something? Introduce a new activity type, AcceptSomething.

But now I am fairly certain that Add and Remove should be avoided too, for similar reasons. They all look the same. To figure out what is happening, you may try to resolve target, but that doesn't help because all collections have either Collection or OrderedCollection type and usually there is no property indicating the purpose of the collection.

Hence, AddToMyCollection is much better than Add.

Add and Remove should only be used for representing side-effects: https://codeberg.org/fediverse/fep/src/branch/main/fep/fc48/fep-fc48.md#activities-and-side-effects

#ActivityPub

User not found: Validation Error: forgefed.NodeInfo: Field node.SoftwareName contains the value mitra, which is not in allowed subset [forgejo gitea mastodon gotosocial]

we can do this the easy way or the hard way

Updating FEP-5219: Groups and permissions: https://codeberg.org/fediverse/fep/pulls/944/files

I've introduced a new property, audiences, which lets you define collections containing actors with a specific role / privilege / affiliation:

{ "id": "https://social.example/group", "type": "Group", "audiences": { "admin": "https://social.example/group/admins", "moderator": "https://social.example/group/moderators", "member": "https://social.example/group/members" } }

For example, you can use such collection to address an activity to group admins.

These collections are also needed for interactionPolicy declarations, which has appeared in some proposals related to private groups.

#fep_5219

https://ipshipyard.com/blog/2026-the-end-of-ipfs-at-shipyard/

Projects maintained by Shipyard will no longer have dedicated maintainers responsible for new features, bug fixes, releases, or long-term stewardship. These include: Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check, and others.

🥀

This will be my excuse for removing the IPFS integration from Mitra in 6.0 release

FEP-171b has been updated: https://codeberg.org/fediverse/fep/pulls/931

The document now mentions canReply property which is used in reference implementations (Streams and Forte).

{ "type": "Note", "canReply": ["https://alice.example/followers"], ... }

#fep_171b #ConversationContainers

Autistici/Inventati’s Press Release, 5 September 2026 Banca etica shuts down A/I funds

-- https://keepitfree.ai/announcements/banca-etica-shuts-down-a/i-funds/

This is not surprising. Sanctions make you toxic - nobody wants to be accused of terrorism financing or money laudnering. Your bank accounts are frozen and centralized services deplatform you (some may remember TornadoCash and other similar cases).

There are two solutions to this problem: physical cash and decentralized digital currencies. Physical cash only works at small scale, and in some places it is gradually being phased out. The second solution is better. However, A/I donation page says "Sorry, but we don’t accept Bitcoin" and links to a post from 2013 explaining that bitcoins "do not give any specific advantage compared to a normal bank account" and is a "pump & dump done to dupe the ultra-libertarian anarco-capitalists".

Well, fortunately, ultra-libertarian anarco-capitalists didn't see it that way and have spent all these years studying the blade building a parallel financial system which nobody can shut down - even US.

Bitcoin is not perfect but it is much better than a bank because no one can shut down your account. You shouldn't be accepting donations in Bitcoin, though - that would put donors at risk. The chain is transparent and the privacy tricks that exist in Bitcoin (e.g. mixers) are generally counter-productive when you're facing a powerful adversary because they make you stand out of the crowd. The real purpose of Bitcoin is to be a bridge between fiat money and Monero, where everything remains hidden: the sender, the recipient and the transcation amount. Besides meeting in person, it is the only safe way to buy a coffee for a Specially Designated Global Terrorist

Is there anyone from Mastodon? Do you see the quote?

(I'm testing stateless mastodon quote approvals)

RE: https://mitra.social/objects/01a04a26-eede-72b0-a5e9-f244c3ff2142

SWICG in a nutshell: open a ticket, sign an agreement, join a meeting

It is essentially an email job. Imagine coming to fediverse and doing this

RE: https://cosocial.ca/users/evan/statuses/117186074437781518

#APx v0.27.0

https://docs.rs/apx_sdk/0.27.0/apx_sdk/index.html

Starting with this version, all DID methods are allowed in the authority component of an 'ap' URI. This change was made to enable experiments with DID methods other than did:key.

Full changelog: https://codeberg.org/silverpill/mitra/src/tag/apx-v0.27.0/apx_sdk/CHANGELOG.md

Updating FEP-5219: Groups and permissions:

https://codeberg.org/fediverse/fep/pulls/916/files

The biggest change here is the replacement of "follow" and "participate" privileges with "view" and "create". Follow and Join are now described separately in the context of follower/participant statuses (which are not privileges - they are used for addressing activities).

#fep_5219

The ap-next developer guide was removed from the https://activitypub.rocks website: https://github.com/swicg/activitypub.rocks/issues/63 (by the father of the Fediverse, no less).

The reason:

It's a fork outside the SocialCG.

This is utter nonsense. The guide refers to the original ActivityPub specification and even to SocialCG reports covering Webfinger and HTTP signatures. The other ap-next project is NomadPub - a collection of FEPs that significantly expand the capabilities of the protocol but don't diverge from the original spec.

However, since dissenting opinions about the present and the future of ActivityPub are now openly censored, a fork may indeed be necessary.

Say goodbye to Linked Data Signatures

https://blog.joinmastodon.org/2026/08/mastodon-4.7/

We now support verifying FEP-8b32 Object Integrity Proofs using either eddsa-jcs-2022 or mldsa44-jcs-2024.

The latest version of Mastodon can verify FEP-8b32 integrity proofs, which replace outdated Linked Data Signatures.

Docs: https://docs.joinmastodon.org/spec/security/#fep-8b32

#activitypub #fedidev #fep_8b32

Mitra has arrayref in its dependency tree but it is pinned to an old version.

RE: https://social.rust-lang.org/users/rust/statuses/117127366248165334

I think Mastodon's new UI design is good. It appears to be evolving in the same direction as #Mitra. For example, our "Lists" are already called "Custom feeds" and there is a hidden "Explore" page which will soon be added to the sidebar, replacing "Local", "Federated" and "Profile directory" (this is to free some space for new features such as groups)

RE: https://mastodon.social/users/Mastodon/statuses/117117221397911074

Updating FEP-5219: Groups and permissions: https://codeberg.org/fediverse/fep/pulls/908

I added two flags that indicate whether a group is private, semi-private or public: canFollow and canParticipate. These flags are similar to ones used in interactionPolicy pattern but I think interaction policies don't scale well.

There is now a thread on SocialHub if you prefer it for FEP discussions: https://socialhub.activitypub.rocks/t/fep-5219-groups-and-permissions/8855

#fep_5219

Mastodon 4.7 beta supports FEP-521a: Representing actor's public keys and FEP-8b32: Object Integrity Proofs (inbound only for now)

I also see FEP-8967: Generating link previews for attached links in the changelog.

It looks like FEP process is actually working?

RE: https://mastodon.social/users/MastodonEngineering/statuses/117071692327950548

The biggest problem for peer to peer ActivityPub is the fact that ActivityPub is primarily a "pull" protocol. You need to fetch a remote actor before interacting with it. This is not feasible in the environment where nodes are intermittently online.

What if we used a special activity to request objects? I've described this idea in more detail in Asynchronous object retrieval:

https://codeberg.org/silverpill/feps/src/branch/main/aef6/fep-aef6.md

I think this mechanism, if combined with self-authenticating objects, should make ActivityPub compatible with store and forward protocols.

#p2p #dtn #fep_ef61