Home | Notifications | New Note | Local | Federated | Search | Logout
silverpill@silverpill@mitra.social
Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. I help maintain the FEP repository and write my own FEPs too. Currently working on ActivityPub Next.
Code: https://codeberg.org/silverpill/
Matrix: @silverpill:unredacted.org
XMPP: silverpill@were.chat
$XMR: 48YM8jwJqDkeUvD38vepSXFeMZH1zsjbvGwTTuaNSSq6Q5GyeWaeiheAZUsSmNn72YdyLpw8geb4FL3opZfGbguJLUj8Mi9
XMR subscription: https://mitra.social/@silverpill/subscription
PGP: 0541 49E3 0F91 C6D7 8FFA C49C 955F 5A6E 2123 25F0
OMEMO fingerprint: 689a2fb0ec87a9481fb45cb7d8870da6aeb4d8247bd69a39017701133b901f04
Matrix (backup): @silverpill:poa.st
Joined: 2026-01-05 16:03:27
435 notes, 1 following, 0 followers
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-05-24 06:07:26)
@phnt Yesterday, a proposal was submitted that offered a solution to this exact problem: https://codeberg.org/fediverse/fep/src/branch/main/fep/baf5/fep-baf5.md. I don't like some parts of it (see discussion), but it's a step in the right direction
Reply to @0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd@mostr.pub
silverpill@silverpill@mitra.social (2026-05-24 05:50:38)
@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd @8c593cc6084205228f9d5f826249596710bbbee6236d54e2c74b2826d00e4c83 It's hard - but not too hard, people launch new ActivityPub projects all the time. I considered Nostr back in 2023 but now it's too late, because I designed a protocol that I believe is better than Nostr, and its backward compatible with Fediverse (so it inherits its network effects).
Reply to @evan@cosocial.ca
silverpill@silverpill@mitra.social (2026-05-24 05:39:15)
@evan This is my mistake, thanks for pointing out. It should be changed to "...where embedded objects are owned by another local actor".
I think Create.object.attributedTo == Create.actor is a different thing, because it is related to authorization, whereas the requirement we're discussing here is related to authentication.
In general, yes, none of this was built into ActivityPub. But over the years implementers figured out authentication and authorization on their own, and now this is how federation works. People expect that same-origin embeddings can be cached as is, without re-fetching.
@general
silverpill@silverpill@mitra.social boosted:
@jae@mastodon.bsd.cafe (2026-05-24 00:52:47)
as the world turns, does does single-binary #fediverse frontends. just implemented background pollling for notifications with a subtle indicator. still sitting at ~14mb binary tested against #pleroma #mastodon #gotosocial #mitra
---Attachments---
image: https://media.bsd.cafe/bsdmmedia01/media_attachments/files/116/624/687/166/850/305/original/cb93f47b41219953.png
Reply to @jae@mastodon.bsd.cafe
silverpill@silverpill@mitra.social (2026-05-24 05:12:50)
@jae tui? looks great
Reply to @8c593cc6084205228f9d5f826249596710bbbee6236d54e2c74b2826d00e4c83@mostr.pub
silverpill@silverpill@mitra.social (2026-05-24 05:11:08)
@8c593cc6084205228f9d5f826249596710bbbee6236d54e2c74b2826d00e4c83 @0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd
ActivityPub.
We now getting capabilities previously available only on SSB & Nostr. Key-based identity, local-first clients.
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-05-24 05:00:56)
@phnt @feld @lain That's correct. Activities are added to local outbox and sent to the gateway when it becomes available.
Reply to @silverpill@mitra.social
silverpill@silverpill@mitra.social (2026-05-24 04:56:26)
@phnt Following on one of our conversations, I now call out authorized fetch as ineffective when it is used on public objects:
Some servers require an HTTP signature in an attempt to limit access to public objects. In this scenario, the request is expected to be signed with a key that is owned by a server actor. However, this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.
silverpill@silverpill@mitra.social (2026-05-24 04:52:17)
FEP-fe34 (Origin-based security model) update : https://codeberg.org/fediverse/fep/pulls/849
I tried to better explain the assumptions on which the model is based, and clarified how exactly origins should enforce boundaries between actors:
Servers MUST ensure that activities published by a client do not represent unauthorized actions. This includes activities embedded within other activities and objects.
Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.
Lemmy API and Mastodon API implementers don't have to worry about this, but one needs to be very careful when accepting arbitrary payloads from clients, for example, when implementing ActivityPub C2S API or FEP-ae97 API. Unfortunately, these security issues are completely ignored by people who push for wide deployment of ActivityPub C2S API.
Another addition is the recommendation to not use partially embedded objects, because that might lead to cache poisoning:
Embedded non-anonymous objects SHOULD NOT be partial representations. A server that relies on embedding for authentication might save a partial representation of an object to the cache, replacing the full object.
(see this issue for details: https://codeberg.org/silverpill/feps/issues/21)
#fep_fe34 #activitypub
silverpill@silverpill@mitra.social boosted:
@peertube@framapiaf.org (2026-05-23 18:17:17)
**v8.1.8 Important security upgrade**
We have learned that the SQL injection vulnerability fixed in v8.1.6 has been exploited at scale since at least May 18, 2026 and so before the v8.1.6 release.
We released a new version that remove all user token access gained before v8.1.6. We also explain the attack in the changelog and the countermeasures taken by this release.
**Please upgrade to v8.1.8 as soon as possible.**
https://github.com/Chocobozzz/PeerTube/releases/tag/v8.1.8
Reply to @julian@activitypub.space
silverpill@silverpill@mitra.social (2026-05-23 16:21:02)
My understanding from a reading of the relevant section from fe34 suggests a claim of A → B is reciprocal if there is an inverse claim B → A.
Yes, and in my understanding these claims are:
- This actor is authorized to delete/update this object.
- This object is hosted on the server where this actor is an administrator.
But I don't insist on importing this concept.
I would want to point out that keeping with prior art has the benefit of making this FEP much easier to adopt by threadiverse implementors.
I consider myself a threadiverse implementer too, and I don't really like the idea of dealing with ambiguous properties :)
At the very least, could you add inbox and outbox properties to the Application actor example? https://codeberg.org/devnull/feps/src/branch/instance-admins/fep/baf5/fep-baf5.md#instance-actor-and-application-actor
Reply to @julian@activitypub.space
silverpill@silverpill@mitra.social (2026-05-23 08:07:40)
Wasn't aware this was a problem? Figured the redirects would be okay.
The canonical location of a FEP is on Codeberg, but no, it is not a problem.
#2 I suppose supercedes is the incorrect term. It extends fe34, in a way. Would that be acceptable? Definitely not meaning to imply that fe34 is insufficient in any way.
"Extends" is fine, I just think you're describing a reciprocal claim from FEP-fe34, so you could use that term (or maybe FEP-fe34 needs to be updated if "reciprocal claim" is not a good name for this mechanism?)
silverpill@silverpill@mitra.social (2026-05-23 07:25:44)
1. I find the use of attributedTo here confusing, because normally this property is used to indicate who owns an object or a collection, and its value is an actor. I am aware that attributedTo is used in a similar way in FEP-1b12, but it would be better to introduce a new property (administrators) instead of continuing to abuse attributedTo.
2. You say that your FEP supersedes the same-origin assumption described in FEP-fe34, but I think it describes a reciprocal claim, also described in FEP-fe34: https://codeberg.org/fediverse/fep/src/branch/main/fep/fe34/fep-fe34.md#reciprocal-claims. I suggest clarifying which aspect of FEP-fe34 is being superseded.
3. In the section "Security and Authorization" you say "authenticity" but what actually is being verified is a permission.
4. The entire problem of non-same-actor updates and deletes can be avoided by using different activities. For example, Update can be replaced with an annotation activity. Delete can be replaced with Remove (from thread).
5. FEP links lead to w3id.org site, not directly to FEPs.
Reply to @tadano@mt.watamelon.win
silverpill@silverpill@mitra.social (2026-05-23 04:30:57)
@tadano @MK2boogaloo The proposed solution sounds reasonable. I'll give it a try.
silverpill@silverpill@mitra.social (2026-05-23 04:13:56)
@billstatler @fediversereport @Mastodon @matrix And ActivityPub is not public-by-default. One could say that about Mastodon where the default post visibility is "public", but ActivityPub is private by default.
If an ActivityPub object is not addressed to anyone via to and cc, it is literally invisible.
Reply to @julian@activitypub.space
silverpill@silverpill@mitra.social (2026-05-23 03:14:22)
@julian @rimu Do you want specifically FEP-2677? Please consider using FEP-d556 instead, it is very similar to FEP-2677 but doesn't require NodeInfo. Also, it is FINAL.
Reply to @caohuak@moon.lonewolf.zone
silverpill@silverpill@mitra.social (2026-05-23 03:07:10)
@caohuak Awesome.
Reply to @chlo@w.chlo.is
silverpill@silverpill@mitra.social (2026-05-21 23:02:58)
@chlo @caohuak Good to know. I am thinking about adding a configuration option that enables embedding for Accept(Follow) activity.
Reply to @chlo@w.chlo.is
silverpill@silverpill@mitra.social (2026-05-21 07:00:58)
@chlo Did that change fix the Sharkey problem?
@caohuak
Reply to @tadano@mt.watamelon.win
silverpill@silverpill@mitra.social (2026-05-21 06:36:42)
@tadano
>why instances like ryona.agency, tsundere.love, annihilation.social aren't loading images
Might be caused by bad connectivity.
But if this behavior is consistent, I could look into it.
>why @relaystalker is STILL getting stuck on follow requesting with relay accounts
https://github.com/yukimochi/Activity-Relay/issues/102
Maybe a clanker could fix it?
>how to get tor/tor federation up with this docker setup
>how to federate over I2P
https://codeberg.org/silverpill/mitra/src/branch/main/docs/onion.md
https://codeberg.org/silverpill/mitra/src/branch/main/docs/i2p.md
But I don't know how to make it work with docker
>duplicate key bug
I am interested in debugging this. Database integrity should be maintained.
>how to pull past posts from profiles quickly so I am not looking at a profile timeline with gaping holes
Make yourself an admin and click on "Load latest posts" in profile menu.
Reply to @tadano@mt.watamelon.win
silverpill@silverpill@mitra.social (2026-05-21 06:23:06)
@tadano @p @relaystalker @Wiz @mischievoustomato It's a correct description.
Reply to @julian@activitypub.space
silverpill@silverpill@mitra.social (2026-05-21 06:18:00)
No, it's not wrong.
I think the good of group moderation currently outweighs the theoretical bad of same-origin impersonation.
silverpill@silverpill@mitra.social (2026-05-21 05:57:34)
- https://github.com/mastodon/mastodon/releases/tag/v4.5.10
- https://hollo.social/@fedify/019e4675-05bc-7725-bcf4-aa51d6af70a0
- https://shrimp.meow.company/notes/amhmis327j0wve4w
- https://shrimp.meow.company/notes/amhmiqtsbwgmt158
- https://activitypub.software/TransFem-org/Sharkey/-/releases/2025.4.7
- https://hubzilla.org/item/53f3509f-d63d-494c-a431-ac84df9c6a57
- https://w.on-t.work/activitypub/may-2026-vulnerability
>Fix Linked-Data Signature bypass through JSON-LD graph restructuring features
JSON-LD adds nothing to Fediverse except bugs and security vulnerabilities.
Of course, there is an alternative to Linked Data signatures that doesn't require Linked Data, much simpler and more secure:
FEP-8b32: Object Integrity Proofs
#activityPub #fedidev
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-05-21 05:32:48)
@phnt @tadano @mischievoustomato Yeah I also figured out automated publishing to the package registry: https://codeberg.org/silverpill/minimitra/src/branch/main/.woodpecker/build.yaml#L20
Haven't tried to publish deb yet, but according to the documentation deb is supported.
silverpill@silverpill@mitra.social (2026-05-21 05:04:46)
@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd This is one of the reasons I don't build on Nostr. It's full of delusional bitcoin cultists
Reply to @mischievoustomato@tsundere.love
silverpill@silverpill@mitra.social (2026-05-21 05:03:21)
@mischievoustomato @tadano I figured out how to do CI, so now we can build packages automatically on Codeberg
Reply to @silverpill@mitra.social
silverpill@silverpill@mitra.social (2026-05-21 04:49:51)
Is the assumption on which FEP-fe34 is based valid?
Of course, it is primarily a philosophical question. Who should be responsible for enforcing boundaries between actors hosted on the same server, the sender or the recipient? In my opinion, the answer is clear: the sender should be responsible.
As far as I know, the majority of existing implementations do enforce boundaries between actors. I am not aware of any implementation that doesn't do that.
Enforcement of boundaries is challenge for generic ActivityPub servers, but it's not insurmountable.
silverpill@silverpill@mitra.social (2026-05-21 04:34:44)
I agree out of principle that the security implications exist, but if you follow through with the exploit, it requires a non-compliant server to allow users to publish Update and Delete for other users on the same instance, and even then the exposure is limited to users of that origin only (e.g. your server cannot arbitrarily delete my posts). This is the foundation of the Origin-based security model.
Correct. FEP-fe34 is based on the assumption that originating servers enforce boundaries between actors. This is stated in the section "Assumptions":
The origin-based security model is designed for use in a network where a server is resposible for enforcing security boundaries between the hosted actors. Servers that publish objects without validation are not supported.
In some cases, FEP-fe34 recommends same-actor policy as an additional protection against implementation bugs and against implementations that don't enforce actor boundaries on purpose. Update/Delete authorization is one of those cases (admittedly, the wording is a bit confusing in that paragraph...)
silverpill@silverpill@mitra.social boosted:
@n0iroh@mastodon.social (2026-05-20 22:43:14)
Post-Quantum key exchange in iroh? Thanks to the amazing #rustlang ecosystem and iroh depending on industry-stanard TLS used in a p2p-friendly way this is now possible: https://www.iroh.computer/blog/iroh-post-quantum-handshakes
#pqc #p2p #iroh
Reply to @tadano@mt.watamelon.win
silverpill@silverpill@mitra.social (2026-05-21 02:46:26)
@tadano
There is a list of breaking changes: https://codeberg.org/silverpill/mitra/src/branch/main/docs/mitra_5_0.md
But most likely none of this affects you
Older Notes