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
429 notes, 1 following, 0 followers
Reply to @patrickleavy@mastodon.social
silverpill@silverpill@mitra.social (2026-07-16 04:42:24)
@patrickleavy It's getting closer:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
silverpill@silverpill@mitra.social (2026-07-12 15:44:46)
Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883
I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.
No, there are 3 options:
- Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
- Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
- Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.
Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini
#fep_ef61 #NomadicIdentity
silverpill@silverpill@mitra.social (2026-07-07 05:20:33)
Finally implemented FEP-0806: Simple client-side encryption in Mitra Mini. Right now it only does encryption-decryption. No delivery yet - because gateways don't support EncryptedActivity activities.
The scheme was changed to HPKE (RFC 9180 Hybrid Public Key Encryption).
#fep_0806
silverpill@silverpill@mitra.social (2026-07-07 00:17:54)
Minor FEP-5219 update: https://codeberg.org/fediverse/fep/pulls/880
I started implementing this FEP in Mitra, here's how an affiliations collection looks like:
https://mitra.social/ap/actors/019f0e0d-b949-7600-aa86-0df8e275c291/affiliations
#fep_5219
silverpill@silverpill@mitra.social (2026-07-05 03:43:36)
I've got a report about Mastodon v4.7.0-alpha.1 not federating with Mitra. Can anybody confirm this?
They recently merged FEP-8b32 signature verification, that might be relevant. All Mitra activities are signed
silverpill@silverpill@mitra.social (2026-07-04 00:29:56)
New @minimitra release: 0.4.2
This version supports post edits. There are also some big changes under the hood that will allow me to copy features from Mitra to Mini with less effort in the future.
RE: https://mitra.social/.well-known/apgateway/did:key:z6MkumzpDj1cYZD2GrBbVT86xL6CfPuyqWZAEXMfSqN9j3hf/objects/019f2891-61e1-77b1-8638-10f33b4d4df9
silverpill@silverpill@mitra.social (2026-07-02 19:30:52)
I'm requesting final comments on FEP-7628: Move actor
#fep_7628 #fep #activitypub
silverpill@silverpill@mitra.social (2026-06-28 20:48:15)
FEP-ef61: Portable Objects has been updated: https://codeberg.org/fediverse/fep/pulls/872
The ap+ef61 URI scheme is now allowed, while ap remains the recommended one. This is to ensure compatibility with @fedify whose maintainers decided to use the ap+ef61 scheme until the specification is finalized.
#fep_ef61 #nomadicidentity
Reply to @harblinger@wizard.casa
silverpill@silverpill@mitra.social (2026-06-15 03:39:00)
@harblinger
I have thought a lot about titles and summaries, but haven't yet decided how to proceed. There are too many special cases.
The top-level heading in a Mitra post is a title, and shouldn't be used as a summary. There is a different attribute for titles in ActivityPub, name. However, If I extract the <h1> and federate it as a name, other Mitra instances will display two titles.
A summary, ideally, should not be displayed anywhere, because it is a summary of content. It's redundant by design. But Mastodon uses it as a "content warning", so Mitra has to insert it into the post to avoid losing important information.
If Pleroma uses summary for "subject", that makes things even more complicated.
There is probably a way to make it all work, but I don't quite understand your use case. What exactly you're trying to implement, a content warning?
Reply to @uriel@bbs.keinpfusch.net
silverpill@silverpill@mitra.social (2026-06-15 02:54:54)
@uriel Yes, I saw the readme, but I need one sentence. Maybe "Fork of the GoToSocial project with IPFS integration"?
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-15 02:48:40)
@phnt I am not talking about this FEP in particular, but about the general principle. Resolving an object may be a SELECT query, while the side effect may be an INSERT query. The details don't matter, it's always two different operations because you don't know what side effect will be needed.
In some cases, the first operation can be avoided by giving activities better names (or by using one of the hacks I mentioned in another post).
There is no associated cost. You get a better protocol and more efficient implementations for free.
@julian @raphael
Reply to @uriel@bbs.keinpfusch.net
silverpill@silverpill@mitra.social (2026-06-15 02:27:12)
@uriel Oh hello there, I have a question about Aktor. Could you provide a short description of the project? In one sentence - it's for @weekinfediverse newsletter.
Reply to @Profpatsch@mastodon.xyz
silverpill@silverpill@mitra.social (2026-06-14 23:19:39)
@Profpatsch @grindhold @sabrinkmann I support vendor prefixes.
Reply to @julian@activitypub.space
silverpill@silverpill@mitra.social (2026-06-14 23:19:08)
@julian @raphael With Accept, you need to resolve Accept.object in order to know what side effects to apply. Usually it's an extra database query. With AcceptFeatureRequest, you can apply side effects right away.
Reply to @mariusor@metalhead.club
silverpill@silverpill@mitra.social (2026-06-14 23:14:22)
@mariusor (3) carries the risk of cache poisoning because the recipient can't tell whether the embedded object is full or partial.
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-14 23:09:40)
@phnt @mariusor I am okay with this option https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723/65
But the subtype is not always determined by object. Sometimes it's target or another property. Nowadays my preference is 1.
Reply to @silverpill@mitra.social
silverpill@silverpill@mitra.social (2026-06-14 22:39:14)
@mariusor What kind of side-effect hint would you prefer?
1. Specialized activity name
{
"type": "AcceptFeatureRequest"
"object": "https://social.example/request"
}
2. Additional property
{
"type": "Accept",
"object": "https://social.example/request",
"objectType": "FeatureRequest"
}
3. Embedded object (possibly partial):
{
"type": "Accept",
"object": {
"id": "https://social.example/request",
"type": "FeatureRequest"
}
}
Reply to @raphael@mastodon.communick.com
silverpill@silverpill@mitra.social (2026-06-14 22:32:43)
@raphael @phnt In a way, yes. My personal preferences:
1) self-describing objects (better DX)
2) more efficient processing
Reply to @mariusor@metalhead.club
silverpill@silverpill@mitra.social (2026-06-14 22:28:58)
@mariusor Activity type is not the only meaningful information about the side-effect, but in many cases a custom type could help with the identification.
Reply to @raphael@mastodon.communick.com
silverpill@silverpill@mitra.social (2026-06-14 22:20:47)
@raphael @phnt I don't think there is a difference.
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-14 22:18:42)
@phnt
You ideally should verify that AcceptFeatured refers to the type of the Object as expected, effectively doing the same thing anyway.
It is not the same thing because you skip one expensive operation: determining the subtype of activity.
You also need to add that as a supported type to your Acccept/Reject validator since they are basically the same, you have to modify your activity builder, if you have one, to create these new types if you wish to support creation and not just ingestion.
Is that a problem? I already have different parsers and different builders for different activities.
The same argument can be made about Create/Update Activities which operate on a bunch of Object types. CreateNote/UpdateNote/UpdateActor/... doesn't make sense in my head as well.
Create and Update have an embedded object, so they do not require specialized names.
Reply to @mariusor@metalhead.club
silverpill@silverpill@mitra.social (2026-06-14 22:07:12)
@mariusor Wrong about what, using different names for different things?
Only a few activities from Activity vocabulary work well with any type of object. For example Create and Update.
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-14 21:17:23)
@phnt @lain Not long ago I saw a Create activity from Cookifed and the object type was ["Note", "Baking"].
Reply to @chpietsch@fedifreu.de
silverpill@silverpill@mitra.social (2026-06-14 21:13:51)
@chpietsch @alineblankertz @malteengeler Other than FEP process? I don't know
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-14 21:13:01)
@phnt With AcceptFeatured you don't need to determine anything. Because the object type is right here in the activity name
Reply to @julian@activitypub.space
silverpill@silverpill@mitra.social (2026-06-14 21:07:45)
Do you also use the same 10 names for all variables in your code?
Reply to @mattcen@aus.social
silverpill@silverpill@mitra.social (2026-06-14 21:03:21)
@mattcen This is primarily due to implementation quirk of GoToSocial:
https://codeberg.org/superseriousbusiness/gotosocial/issues/3197
AFAIK, Mastodon had a similar limitation in the past, and also was overly strict with actor ID -> webfinger relationships, but the situation has improved since then.
Reply to @chpietsch@fedifreu.de
silverpill@silverpill@mitra.social (2026-06-14 20:58:42)
@chpietsch @alineblankertz @malteengeler Mastodon developers are actually quite active, they published a number a Fediverse Enhancement Proposals. The latest submission was just two days ago:
https://codeberg.org/fediverse/fep/src/branch/main/fep/7aa9/fep-7aa9.md
silverpill@silverpill@mitra.social (2026-06-14 20:54:10)
Mitra.
The recipient of a payment is not necessarily a content creator, it could be a server operator too.
silverpill@silverpill@mitra.social (2026-06-14 20:52:07)
I've been reviewing the new FEP from the Mastodon team today, and one thing that caught my attention is the use of Accept and Reject activities for managing approvals. Another day, someone proposed to use Follow activity for "watching a thread".
So now, when you receive a standard activity, you need to use increasingly complicated heuristics to figure out what the activity does, because it is not possible to infer that from its type anymore.
This has to stop. I think we need to start giving our activities better names.
#ActivityPub
Older Notes