Federated Timeline

Home | Notifications | New Note | Local | Federated | Search | Logout

Federated Timeline


Reply to @0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd@mostr.pub
silverpill@silverpill@mitra.social (2026-05-24 06:28:33)
@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd @8c593cc6084205228f9d5f826249596710bbbee6236d54e2c74b2826d00e4c83 The client is a separate project, Mitra Mini. Partially based on Mitra, but I had to rebuild other parts from scratch.

It is the only implementation, and has at least two users 😆


Reply to @phnt@fluffytail.org
silverpill@silverpill@mitra.social (2026-05-24 06:23:24)
@phnt

>Although you would still need some way to publish that key and a valid Actor for verification, a server.

I just realized that it could be effective in island networks, where domains are allowlisted.


Reply to @silverpill@mitra.social
Alex Gleason@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd@mostr.pub (2026-05-24 06:18:11)
Is Mitra the only serious one who implements it? How many users do you have?


fedicat@fedicat@pc.cafe boosted:
@FediFollows@social.growyourown.services (2026-05-24 05:48:10)
#Ohio USA accounts to follow:

OHIO NEWS
@ColumbusDispatc - The Columbus Dispatch
@clevelandnews - The Plain Dealer / Cleveland.com
@index@oxfreepress.com - Oxford independent local news site

ACTIVISM
@heartlandurbanist (videos) & @mattcaff (personal) - Organiser/urbanist promoting better housing & transit

HAM RADIO
@w8lt - Amateur Radio & RF Club at Ohio State Univ

CULTURE
@index@clevelandwinds.org - Wind ensemble orchestra at Cleveland State Univ

FOOD
@Satoshi - Vegan restaurant in Cleveland

🧵 1/3


fedicat@fedicat@pc.cafe boosted:
@fedihost@mstdn.social (2026-05-24 06:06:46)
RE: https://social.growyourown.services/@FediTips/116625090914322439

We are currently taking steps to mitigate this exploit and will notify those who have been impacted.
#PeerTube


Reply to @0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd@mostr.pub
silverpill@silverpill@mitra.social (2026-05-24 06:09:33)
@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd @8c593cc6084205228f9d5f826249596710bbbee6236d54e2c74b2826d00e4c83 Yes. Relays are usually called gateways, but the architecture is very similar.

https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md


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


FediHost@fedihost@mstdn.social (2026-05-24 06:06:46)
RE: https://social.growyourown.services/@FediTips/116625090914322439

We are currently taking steps to mitigate this exploit and will notify those who have been impacted.
#PeerTube


Reply to @silverpill@mitra.social
Alex Gleason@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd@mostr.pub (2026-05-24 05:58:43)
Is it clients & relays?


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).


FediFollows@FediFollows@social.growyourown.services (2026-05-24 05:48:10)
#Ohio USA accounts to follow:

OHIO NEWS
@ColumbusDispatc - The Columbus Dispatch
@clevelandnews - The Plain Dealer / Cleveland.com
@index@oxfreepress.com - Oxford independent local news site

ACTIVISM
@heartlandurbanist (videos) & @mattcaff (personal) - Organiser/urbanist promoting better housing & transit

HAM RADIO
@w8lt - Amateur Radio & RF Club at Ohio State Univ

CULTURE
@index@clevelandwinds.org - Wind ensemble orchestra at Cleveland State Univ

FOOD
@Satoshi - Vegan restaurant in Cleveland

🧵 1/3


:hosimiya_mion::star_stroke:@hos1miya@misskey.0sakana.xyz (2026-05-24 05:47:56)
:ohayo:


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


Reply to @apps@toot.fedilab.app
fedicat@fedicat@pc.cafe (2026-05-24 05:39:09)
@apps fine line between milestone and millstone


fedicat@fedicat@pc.cafe boosted:
@Feditext@mastodon.social (2026-05-24 05:30:15)
We're back! Brian fixed the issue and Feditext should work again for all of our TestFlight users. If it doesn't, please manually open TestFlight and check for a new build.

#Feditext


Reply to @Feditext@mastodon.social
Feditext@Feditext@mastodon.social (2026-05-24 05:30:15)
We're back! Brian fixed the issue and Feditext should work again for all of our TestFlight users. If it doesn't, please manually open TestFlight and check for a new build.

#Feditext


Fedilab Apps@apps@toot.fedilab.app (2026-05-24 05:22:30)
I read your concerns and I deeply appreciate them. The goal was only to give more visibility on what is being fixed and improved. Things are working well as they are, and some of you warned me about side effects. If I ever start to feel uncomfortable with milestones, from pressure or anything else, I can always tell you and stop. What we all want is to make Fedilab better.


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 @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-05-24 05:20:49)
@silverpill 
>this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.

I never thought about it like that, but that too is a way to circumvent it. Although you would still need some way to publish that key and a valid Actor for verification, a server. If a remote server implementing restrictions on fetching based on signatures only disallows the instance Actor, then that is a way to bypass that restriction. Although I think there currently is no implementation that does that. Mastodon instead blocks everything on the domain including all subdomains and GTS probably does the same. No idea how the Misskey forks and Iceshrimp.NET do it though. Of course using different domains works as well.

>Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor.

Unrelated to the this FEP, but this came up when fixing the recent Pleroma security issues. There is no agreed upon way of federating moderation decisions to remote instances. It is logical when validating remote Update Activities to only allow Activities that update Objects owned by the same Actor, however that is never guaranteed when for example an admin on a remote instance forces a post to be NSFW. Similarly Delete Activities can have the Actor be the moderator, but Object actually owned by user.


Reply to @silverpill@mitra.social
Alex Gleason@0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd@mostr.pub (2026-05-24 05:17:56)
Those things are too hard on ActivityPub. Join the dark side.


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 @silverpill@mitra.social
Evan Prodromou@evan@cosocial.ca (2026-05-24 05:03:52)
@silverpill 

I don't think this makes sense: "Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor." 

We've never had this requirement; it's not built into ActivityPub; it's not how federation work.

- Like
- Announce
- inReplyTo
- Follow
- Accept
- Reject

I think two way verification is a better mechanism than same-origin. So, check that the `object` of a `Create` has the same `attributedTo` as the `actor`.


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.


fedicat@fedicat@pc.cafe boosted:
@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


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.


fedicat@fedicat@pc.cafe boosted:
@benpate@mastodon.social (2026-05-24 03:13:06)
#Fediverse, I need your help.

I have a budget for a small contract to improve #Emissary, and am looking for a talented web designer to create a new default theme for the server.

Highlights:
* Probably ~60 hours of work
* Anywhere in the world
* Must be a good person

Details are here: 
https://benpate.dev/20260601-html-designer

If you know someone who's great with HTML+CSS+Design, and is looking for a short gig, please share this with them :)

#FediHire #GetFediHired


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


fedicat@fedicat@pc.cafe boosted:
@mkljczk@pl.fediverse.pl (2026-05-24 04:35:26)
i think having multiple shitty implementations of a thing is better than having just one shitty implemention of a thing


Jeff@box464@mastodon.social (2026-05-24 04:44:25)
Peter Pan Mini Golf in #Austin 

“Still here. Still weird. Since 1948”

Can confirm the weirdness.
---Attachments---
image: https://files.mastodon.social/media_attachments/files/116/625/411/791/690/490/original/3fd57f4fce0789c3.jpeg
image: https://files.mastodon.social/media_attachments/files/116/625/412/394/288/026/original/578db2e6a6201ab8.jpeg
image: https://files.mastodon.social/media_attachments/files/116/625/602/077/988/182/original/d4f8360dd2dfd70e.jpeg
image: https://files.mastodon.social/media_attachments/files/116/625/446/314/203/761/original/2e0b75c2bb1ee003.jpeg

Older Notes