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
134 notes, 1 following, 1 followers
Reply to @harblinger@wizard.casa
silverpill@silverpill@mitra.social (2026-03-27 06:17:17)
@harblinger You can say it at https://codeberg.org/silverpill/mitra
Some fedi developers took an aggressive stance, but I don't care that much. If a bug report is legitimate, then it shouldn't matter what tool was used by the reporter.
silverpill@silverpill@mitra.social (2026-03-27 05:33:59)
@smallcirclesThere are a couple of #ActivityPub projects that focus on providing the good tools that abstract away the complexities of wire-level network commsYou're talking to a developer of such project.
There is no "wire chaos", where did you get this idea from?
@fedify
Reply to @Profpatsch@mastodon.xyz
silverpill@silverpill@mitra.social (2026-03-27 05:11:06)
@Profpatsch @liaizon The guide recommends limiting the response size, to prevent DoS.
I also found this in your SECURITY.md:
https://codeberg.org/Profpatsch/Profpatsch/src/commit/249aa389a2023814b328af8fc795750fd28d995d/users/Profpatsch/activitypub-go/security.md#response-body-size-limits
Reply to @Profpatsch@mastodon.xyz
silverpill@silverpill@mitra.social (2026-03-27 05:04:10)
@Profpatsch You need to create a new signature because the request target is changing. It is a part of a signature base, so the initial signature becomes invalid when the client follows a redirect.
@liaizon
Reply to @Profpatsch@mastodon.xyz
silverpill@silverpill@mitra.social (2026-03-26 06:31:20)
@Profpatsch @smallcircles @phntWhat hasn’t been considered is the ability of multiple people to speak with “one voice” yet.Imageboards?
There was one that federated using ActivityPub: https://github.com/FChannel0/FChannel-Server
silverpill@silverpill@mitra.social (2026-03-26 06:19:12)
@smallcircles Fediverse is not like email because ActivityPub has many different message types. What kind of client API developers use is irrelevant.
Reply to @stefano@mastodon.bsd.cafe
silverpill@silverpill@mitra.social (2026-03-26 04:42:14)
@stefano @rayslava @mitra If some Mastodon API endpoint or field is missing, please let me know. I'll add it.
Reply to @Profpatsch@mastodon.xyz
silverpill@silverpill@mitra.social (2026-03-26 04:39:41)
@Profpatsch2. Activity-Level Origin Checks
Same-origin is checked rather than exact equality so that servers with multiple actors can sign on behalf of any of their actors — a common legitimate pattern.For incoming activities, consider checking exact equality. See FEP-fe34, section "Signatures":In order to minimize damage in the event of a key compromise or insufficient validation, consumers MUST verify that the signing key has the same owner as the signed object. Consumers MUST also confirm the ownership of the key by verifying a reciprocal claim.This is not strictly necessary, but would help if the origin server does poor job at validating user input.3. Embedded Object Origin Checks
Owner origin: the object's owner (actor for Activity subtypes, attributedTo for Notes/Objects) must be same-origin as the signing actor. Anonymous objects (no owner field) are accepted.In this case I also recommend checking owner ID equality, as a rule of thumb. Because origin servers implementing C2S API may fail to validate all embedded objects (which can be deeply nested).Response body size limitsYou may also need to limit the number of redirects and set a timeout. Some HTTP libraries have bad defaults.
By the way, I collect such recommendations in this guide: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md#network. Contributions are welcome!
@liaizon
Reply to @hongminhee@hollo.social
silverpill@silverpill@mitra.social (2026-03-25 06:07:58)
@hongminhee Nice project. But it doesn't support WASM.
Reply to @petitminion@socialhub.activitypub.rocks
silverpill@silverpill@mitra.social (2026-03-24 04:43:42)
This may limit interoperability because audience is supposed to contain IDs (either actor IDs or collection IDs). I think many servers don't even check audience, and rely only on to and cc.
Here's how these special strings could be translated into IDs for to / cc:
- me: current actor ID.
- instance: special collection ID, similar to https://www.w3.org/ns/activitystreams#Public. Prior art: Akkoma uses https://server.example/#Public for local-only posts.
- followers: actor's followers collection ID.
- everyone: https://www.w3.org/ns/activitystreams#Public
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-03-21 05:00:06)
@mkljczk Yeah, when MAEPs? It seems that the work has stalled.
@phnt
Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-03-18 23:04:13)
@phnt smithereen has it: https://codeberg.org/fediverse/fep/src/branch/main/fep/82f6/fep-82f6.md
(by the way, this FEP is in "final comments" stage, so the best time to raise objections / provide feedback is now)
Reply to @astro@c3d2.social
silverpill@silverpill@mitra.social (2026-02-23 04:47:11)
@astro Opened an issue: https://github.com/astro/buzzrelay/issues/136
Reply to @astro@c3d2.social
silverpill@silverpill@mitra.social (2026-02-05 05:39:22)
@astro It didn't. I can open an issue with a detailed report if that would help.
Reply to @silverpill@mitra.social
silverpill@silverpill@mitra.social (2026-02-03 04:56:31)
@astro I announced a tagged post to a hashtag actor, the response was 202. Not sure how to verify, though. Does FediBuzz distribute posts back to the originating instance?
Reply to @silverpill@mitra.social
silverpill@silverpill@mitra.social (2026-02-03 01:48:25)
@astro Apparently I am still affected by https://github.com/astro/buzzrelay/issues/132, can't follow a hashtag. I will try to send the Announce activity manually (without a follow relationship), though this will require a bit of work.
Reply to @astro@c3d2.social
silverpill@silverpill@mitra.social (2026-02-02 22:49:44)
@astro Thank you for adding support for Create/Announce! Do you ingest these activities through hashtag actor inboxes?
This might explain amplification, as hashtags can be followed by regular users too. This is how I use FediBuzz -- I just follow hashtags from this account, and relayed posts appear as reposts (boosts) in my feed.
Reply to @astro@c3d2.social
silverpill@silverpill@mitra.social (2026-01-31 05:24:06)
@astro LitePub was like a dialect of ActivityPub, but LitePub relay protocol - yes, it is used for both publishing and consuming content.
FediBuzz can follow servers and even other LitePub relays, which will Announce public posts to it.
I think FASP is not necessary because we already have similar capabilities in ActivityPub. And those capabilities can be expanded: https://socialhub.activitypub.rocks/t/idea-for-a-more-capable-relay-server/8442
Reply to @astro@c3d2.social
silverpill@silverpill@mitra.social (2026-01-31 04:37:20)
@astro Some servers already have all the necessary capabilities. The missing piece is https://github.com/astro/buzzrelay/issues/79