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 @mint@ryona.agency
silverpill@silverpill@mitra.social (2026-06-14 20:30:17)
@mint It asked to me to click on motorcycles. The future is not evenly distributed :(
Reply to @harblinger@wizard.casa
silverpill@silverpill@mitra.social (2026-06-14 20:25:18)
@harblinger What would be the value of this summary field? Headings are part of the content in Mitra, I can try to extract the first heading from HTML, but this method is not always reliable (we do this for Atom feeds).
>sending notes with that field would be nice for Pleroma interop.
How?
Reply to @yggverse@mastodon.social
silverpill@silverpill@mitra.social (2026-06-14 07:18:49)
@yggverse It was one of the good Nostr clients, everything else requires a spying brick or a web browser (where it makes connections to 10 random sites).
But I'd like to point out that Mitra Mini is still actively developed and already supports proxies.
Reply to @HolosSocial@mastodon.social
silverpill@silverpill@mitra.social (2026-06-14 05:42:00)
@HolosSocial Activity Vocabulary only provides a vague description of a type. It doesn't define what is a valid Follow activity, so you can justify anything by referring to it. ActivityPub, on the other hand, has certain requirements related to Follow activities. For example, we would be required to add the author of a Note (?) to our following collections upon receiving Accept, which doesn't make sense to me.
Even if you choose to ignore ActivityPub - what is the motivation for using Follow activity? It is designed for a specific purpose and it is not clear why you want to use it for something unrelated.
A supporting server tells the two apart by looking at the target: an actor means follow an account, a note means follow a thread.
It is not possible to tell whether it is an account or a note by looking at URI.
@mayel @julian
Reply to @darkwolf@moon.lonewolf.zone
silverpill@silverpill@mitra.social (2026-06-14 04:49:31)
@darkwolf I am currently working on synchronizing mitra and minimitra codebases. It's a slow process, but it will make nearly all Mitra features available in minimitra
Edits will probably be added in the next release.
Reply to @mint@ryona.agency
silverpill@silverpill@mitra.social (2026-06-14 04:41:09)
@mint On what site did you find it? I have never seen anything like that
Reply to @grindhold@23.social
silverpill@silverpill@mitra.social (2026-06-14 04:00:06)
@grindhold
e.g. we had this situation where content was defined as a Proposal as string, whereas in Note it was common to have a mapping from lang-code to a string in the according language as content.
I'm not sure if I understand. Mapping from lang-code to string it not content, it's contentMap: https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues.
Proposal was designed with duck typing in mind. Proposal.content is same as Note.content, Proposal.attributedTo is same as Note.attributedTo. If everyone designs their extensions this way, duck typing works great.
The conflicts might occur but the solution to this is to use better names. So far I seen only one conflict: between Bookwyrm's quote and Mastodon's quote. In such cases you can use type for disambiguation - I am not saying that we should drop type completely. Ironically, though, Bookwyrm does use content negotiation. When it thinks that remote server is not Bookwyrm, it sends a Note instead of the original type, Quotation, thus making disambiguation impossible.
That's exactly how content negotiation will work in practice.
@sabrinkmann @Profpatsch
silverpill@silverpill@mitra.social (2026-06-14 03:37:27)
@mayel My proposal was FEP-f06f: Object observers. But I haven't implemented it yet, and I recognize that creating a special actor for each thread might be cumbersome.
I like the idea of "following" a conversation container, because we can then use its activity distribution method (Add activities), and include all conversation activities, including reactions.
However, according to ActivityPub, Follow should be used on actors: https://www.w3.org/TR/activitypub/#follow-activity-outbox. Also, if the "watch conversation" activity appears identical to a standard Follow activity, it is unclear how one could distinguish between the two.
So if object observers are out of question, I would vote for a custom activity, e.g. WatchConversation.
@julian @apps
Reply to @apps@toot.fedilab.app
silverpill@silverpill@mitra.social (2026-06-13 06:52:13)
@apps ActivityPub's Follow activity is intended to be used on actors: https://www.w3.org/TR/activitypub/#follow-activity-outbox.
This is one of the reasons I proposed that "observer" actor. Another option is to use a custom activity (e.g. Watch).
Reply to @apps@toot.fedilab.app
silverpill@silverpill@mitra.social (2026-06-13 06:18:57)
@apps I wrote this FEP: https://codeberg.org/fediverse/fep/src/branch/main/fep/f06f/fep-f06f.md
Object observer is an ActivityPub actor that can be followed to receive object updates.
However, I never implemented it. Pulling context and replies is often enough.
Reply to @liaizon@social.wake.st
silverpill@silverpill@mitra.social (2026-06-13 06:15:48)
@liaizon Domain names are NFTs rented from ICANN
Reply to @sabrinkmann@hachyderm.io
silverpill@silverpill@mitra.social (2026-06-13 04:30:14)
@sabrinkmann Why create different versions when you can use one?
There are ways in which the Fediverse can accomodate the greater number of different services:
- Content negotiation: every server advertises supported types, and the sender needs to adjust activities depending on what the recipient understands.
- Duck typing: recipients don't filter received objects by type, and instead look at their properties.
I don't think the first approach can work at scale. It's like serving different websites to different web browsers.
(Negotiation can be useful in some cases, though - I even wrote a FEP about this: https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md)
@Profpatsch @grindhold
Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-13 03:44:01)
@mike I still have no idea what your problem is. In the worst case, other implementations will not be able to backfill your conversations, that's all. It's not the end of the world.
Reply to @dansup@mastodon.social
silverpill@silverpill@mitra.social (2026-06-13 03:43:31)
@dansup I appreciate your trust, but there is a problem - I already maintain a resource for ActivityPub developers:
https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md
What's the current state of activitypub.social website? Does it have content? I think it would be cool to use ap-next markdown docs as a source.
silverpill@silverpill@mitra.social (2026-06-12 05:50:21)
FEP-5219: Groups and permissions has been added to the FEP repository.
#fep #fep_5219
RE: https://mitra.social/objects/019e87e9-62a6-71d1-8edc-3a8a63e96c9f
silverpill@silverpill@mitra.social (2026-06-11 22:32:02)
That's the plan. I am trying to introduce new features (such as fine-grained permissions) while keeping it as close to existing implementations as possible.
@nutomic @rimu
silverpill@silverpill@mitra.social (2026-06-11 22:14:16)
I am working a FEP which in some ways is related to your proposal:
FEP-5219: Groups and permissions
It introduces a new collection called affiliations, which is intended as a single source of information on who is allowed to do what (within a specific domain).
The FEP is mainly concerned with FEP-1b12 groups, but the affiliations collection could also be attached to Application actors, and be used in a way you described in FEP-baf5: Administrator Collection
Reply to @jupiter_rowland@hub.netzgemeinde.eu
silverpill@silverpill@mitra.social (2026-06-11 19:57:37)
@jupiter_rowland
Forte has quite a bunch of private, single-user servers, but to my best knowledge, there's only one with open registrations.
Could you share it? I am looking for an instance where I can do federation tests.
@sendpaws @phnt
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-11 19:43:25)
@phnt Nicolium?
Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-11 19:06:01)
@mike
About the 403 - was it fetched by your site actor perchance? They aren't one of my followers. I'm not seeing any permission issues currently, though I'll keep investigating.
No, I am making a request on behalf of my personal actor. Made another attempt at 2026-06-11T10:03:56Z with the same result.
Let's just remove this line from FEP-171b. Then I think I can make most everything else work.
OK, I will remove it.
silverpill@silverpill@mitra.social (2026-06-11 03:20:05)
@trwnh It's a long story, but the gist is that there are major architectural differences between @mike 's implementations and many others. contextHistory was introduced in an attempt to create a conversation backfilling algorithm that works with all implementations
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-11 02:19:52)
@phnt Lol. Maybe it will be included in ActivityPub 1.1 at some point around the year 2040.
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-06-11 02:16:06)
@phnt I only implemented C2S Likes so far. What's the deal with Announces?
The biggest problem with C2S is that objects and activities can be embedded in other activities. I already had some generic validators written for FEP-ae97 API, but classic C2S introduces a new challenge: IDs. It seems that the safest option is for all id properties with local origin to be recursively removed and then re-assigned.
silverpill@silverpill@mitra.social (2026-06-11 01:39:54)
I tried to implement the "standard" ActivityPub #C2S API in Mitra.
It's an interesting exercise, but I am not sure if I'll ever enable it by default. Permitting clients to publish arbitrary JSON is equivalent to allowing them to publish unsanitized HTML. This may be acceptable if you're an admin on a single-user instance, but it is a really stupid thing to do when there are multiple users.
Although it might be possible to validate activities using strict JSON schemas, that would require a lot of work. You may as well create your own API that will have none of those issues.
FEP-ae97 API is also tricky to implement, but at least it offers a genuine advantage over regular REST APIs: nomadic identity. Also, its security is more straightforward because portable actors and objects are namespaced by DIDs.
Reply to @silverpill@mitra.social
silverpill@silverpill@mitra.social (2026-06-10 23:54:49)
@joe It is now available in the UI, "Load conversation" in the post menu
Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-10 19:27:43)
@mike
I might argue that what this represents is quite literally a "filtered view"...
That's fine, I fixed it on my side.
However, now I'm getting 403 responses when ?posts=true is present. At the same time, unfiltered collection can be retrieved without issues.
My normalised-comparison function doesn't alter the original. Will review the portable objects implementation shortly and make certain I got that part right.
The normalization algorithm recommended in FEP-ef61 removes query parameters because there is a magic query parameter gateways, which is used for location hints:
ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor?gateways=https%3A%2F%2Fserver1.example,https%3A%2F%2Fserver2.example
I thought that there will be more magic parameters and decided to "reserve" the entire query component (quoting section 'ap' URIs):
The query is OPTIONAL. To avoid future conflicts, implementers SHOULD NOT use parameter names that are not defined in this proposal.
But of course, we need them to filter collections, so this is not a hard requirement (SHOULD, not MUST)...
But I would be happy to implement it if it would allow us to all co-exist in the same fediverse.
I think a filtered view is fine, but you could also choose to not publish this collection - it is not required by FEP-f228. Other implementations should be able to backfill conversation using the contextHistory property.
Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-10 06:23:02)
@mike I see activities, but I figured out why. The URL is normalized before fetching and ?posts=true parameter is removed during the normalization.
This is because query parameters are not significant in 'ap' URIs:
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#comparing-ap-uris
Not sure how to deal with this. I think collections shouldn't have query parameters in their IDs, but query parameters should be allowed in collection views (when filtering is applied).
Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-09 18:25:27)
@mike
Yes, whenever the context element is referenced from a naked object per the current FEP-f228.
I tried to fetch context from one of your (private) posts, but the collection contains activities:
https://macgirvin.com/.well-known/apgateway/did:key:z6MkhPXNfiHDh2qSNjFzZ9yY27C1iHnHVbb1eaxuoiEe4tjk/conversation/bf59f105-711d-4c71-96a3-923e90f76e18?posts=true
but trying to still provide reactions since our software considers them to be an integral part of the conversation
One way to provide reactions when only "collection of posts" is available is to use likes and emojiReactions collections, but I doubt that any implementation would actually resolve them.
Reply to @hongminhee@hollo.social
silverpill@silverpill@mitra.social (2026-06-09 16:43:44)
@hongminhee
>So I would not phrase it as “documentation or multicast addresses are always practical SSRF targets.”
But could they be, even in theory? I found that 100.64.0.0/10 is indeed used for private networks, but it seems that allowing requests to documentation or multicast addresses has no security impact.
Reply to @mike@macgirvin.com
silverpill@silverpill@mitra.social (2026-06-09 06:11:17)
@mike Forte is already listed as an implementer of "collection of activities". Does it also provide "collection of posts"?
@julian
Older Notes