Phantasm@phnt@fluffytail.org

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

Phantasm@phnt@fluffytail.org

Professional thread derailer.
Bad posts ahead.

Alts when my instance is broken: @phnt@pl.borked.technology @phnt@annihilation.social

pfp and banner shamelessly stolen from Alessandra Maria

76 69 84 39 83 32 65 76 76 32 76 79 86 69 32 76 65 73 78

Public XMPP (Almost never checked): phnt [at] 404 dot city
An attempt at a blog: https://evilmaid.net
Joined: 2026-02-23 22:10:33
43 notes, 0 following, 0 followers


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-14 23:35:07)
@silverpill @general @julian @raphael 
>Usually it's an extra database query. With AcceptFeatureRequest, you can apply side effects right away.

If you are receiving Accept for something, there's probably a check somewhere if the Accepted thing exists to you anyway. Not doing so in the context of this FEP would result in adding a possibly non-existent Object to a Collection. If you store AP Activities/Objects as JSON in your DB the type comes for free with the existence check. If your AP data is more normalized, then yes you would have to join tables using indexes, or possibly re-query the DB to include the type.

Reject might need the same checking as Accept or might not depending on the target.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-14 22:55:03)
@silverpill @mariusor 2


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-14 21:28:22)
@silverpill You ideally should verify that AcceptFeatured refers to the type of the Object as expected, effectively doing the same thing anyway. 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.

So instead of some long switch/case statement on an Object type, you now have a long list of Accept*/Reject* types that all have the same semantics just operating on different types. And more handling in your validators/builders.

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.


Reply to @lain@lain.com
Phantasm@phnt@fluffytail.org (2026-06-14 21:10:16)
@lain @silverpill Somebody probably made that already. Objects with type arrays have been talked about recently-ish I think. Those are even more insane and should be made into a specific type instead.

https://codeberg.org/fediverse/fep/src/branch/main/fep/2277/fep-2277.md#multi-typing


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-14 21:04:49)
@silverpill 
>And one thing that caught my attention is the use of Accept and Reject activities for managing approvals.

This is an ActivityPub issue more than anything else. The "spec" is clear that the side-effects are to be determined by the type of the Object. There is no other indication, you effectively must check the type of the Object referenced. And I think that is correct, the same way Mastodon is correct in its usage of these two Activity types.

If you split the type for other Accept/Reject Activities, like AcceptFeatured or whatever, you are still left with more type determining logic anyway [at least in function non-pattern matching languages :)]. You just moved it somewhere else instead.


Reply to @jupiter_rowland@hub.netzgemeinde.eu
Phantasm@phnt@fluffytail.org (2026-06-11 04:45:43)
@jupiter_rowland @evan @kissane @sendpaws 

Where do you think ActivityPub came from? It wasn't Eugen Rochko who invented it.

I know the history, don't worry.

Also, the very first server application that implemented ActivityPub was Hubzilla in July, 2017, two months before Mastodon which started out on the same protocol as StatusNet.

Yet Mastodon is basically the reason why ActivityPub became a W3C recommendation after 2 (I think) deadline extensions. Without Mastodon ActivityPub probably would never become a W3C recommendation. And since then, they've been going on their quest of hijacking the specification and/or forcing their ideas on the network. One that happened quite early on was Mastodon's hijack of the summary field for content warnings which wasn't used for that previously. Now their "hijacks" are more on the side of centralizing moderation and overall working on features that aim to reduce the social aspect of the network and increase witch hunting. Like the new "follow packs" or whatever they called them which will definitely never turn into "block packs" that will inevitably end up maintained by heavily opinionated people like on BlueSky.

The reason why Mastodon doesn't have groups isn't because ActivityPub doesn't really support them. It's because Twitter has never had groups.

They way public groups work currently is very non-ideal and prone to spam, since it's just an account that auto-repeats all posts mentioning it. I have some ideas on how to fix groups and make them actually usable, but making the different implementations interoperable and achieve consensus won't be easy.

picrel

Except for the thermonuclear option, Forte (https://codeberg.org/fortified/forte) does literally all of this with ActivityPub Don't mix up ActivityPub and Mastodon.

But does it work outside of the few Forte instances and the few servers supporting the so-called Threadiverse? If those posts with those permissions federate as normal posts, have a public post represe
---Attachments---
image: https://upload.fluffytail.org/media/e6/27/46/e62746b280dfe91e9298c37ee56f1da0ecb687e27d544c7c8a2b6481bfb011cf.png?name=pleroma-groups.png


Phantasm@phnt@fluffytail.org (2026-06-11 02:22:45)
Didn't expect a dedicated foxes column to go so hard.
image.png
---Attachments---
image: https://upload.fluffytail.org/media/f7/ea/94/f7ea94d3fb5a93fec085287ee6bd8b07ebef4f2b9575620d2092f2e6794cf2bb.png?name=image.png


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-11 02:16:59)
@silverpill The joke is that C2S Announces aren't defined in the spec.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-11 02:02:32)
@silverpill 
>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.

This is how Pleroma does it. Posts made via C2S all go through the object validators like any other post. Problem is that due to how some things are federated, an object validator made for validating incoming federation might not be sufficient for validating objects for outgoing federation and some additional checks are needed. Which is exactly how the different permission bypasses worked, which led to C2S being disabled by default. I don't think it's worth the added work and maintenance burden.

Also have you implemented C2S Announces ;)?


Reply to @jupiter_rowland@hub.netzgemeinde.eu
Phantasm@phnt@fluffytail.org (2026-06-10 20:07:09)
@jupiter_rowland @sendpaws 
>Not the whole Fediverse is social media.
>Social media is all about unidirectional followers and churning out content to as many people as possible...

The protocol is described as a social networking protocol in its abstract. That people managed to bolt on forums and marketplaces on top of it is more of a testament to its stupid levels of extensibility. And to me social media qualifies as anything that isn't a blog that allows comments. Since that is its dictionary definition more or less. AIM was social media, Twitter is social media, Fediverse is social media. They are all medias that allow social interactions.

Abstract
The ActivityPub protocol is a decentralized social networking protocol based upon the ActivityStreams 2.0 data format.
---
websites and computer programs that allow people to communicate and share information, opinions, pictures, videos, etc. on the internet, especially social networking websites
- Cambridge dictionary

>It would have allowed for discussions with restricted permissions, made absolutely impenetrable even for Mastodon users. It would even have allowed for discussion groups which would have been both fully private and hidden from all directories. Most importantly, it would have empowered its users to moderate their own streams themselves with a whole arsenal of countermeasures, all the way up to the thermonuclear option of turning ActivityPub off entirely.

You can't have any of this when using ActivityPub. And if you turn off ActivityPub federation then you've created a website with comments. There is nothing private on this network besides end-to-end-encrypted DMs which are very much in a prototype stage still. This whole network operates on an implied trust that nobody does anything malicious, but that is a faulty assumption that never held up. Trying to make ActivityPub resilient to it would have reinvented XMPP with different semantics and probably much more complicated. Even stuff like Conversation


Reply to @phnt@fluffytail.org
Phantasm@phnt@fluffytail.org (2026-06-10 05:41:48)
@jupiter_rowland @sendpaws Not to mention that limiting social interactions on a social media network is kinda sad. There are better ways to filter posts you don't like seeing in your notifs than breaking federation and/or making social media less social.


Reply to @jupiter_rowland@hub.netzgemeinde.eu
Phantasm@phnt@fluffytail.org (2026-06-10 03:22:04)
@jupiter_rowland @sendpaws 
>About "reply gating"
>This, or something similar, has been a standard feature at least on Hubzilla, (streams) and Forte from the get-go, i.e. from their respective creation on.

I've written extensively about this before. Features like this simply cannot work in a federated network like ActivityPub broadly. Your instance might hide replies/comments to your posts to you and other instances running the same software, but it is visible to everyone else. So at best it creates a false sense of security/control.

The only way to implement it properly is by making the OP instance/user the sole authority of federating those posts, which requires a large paradigm shift in how federation works. FEP-171b: Conversation Containers is one such way and it is effectively broken for every other implementation beyond those listed. Hubzilla implements it. So you either limit your interactions to 4 fedi server implementations that most people don't use, or it doesn't work as expected.

Give my blog post about it a read if you are interested in how these settings can be disregarded.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-06-01 17:39:31)
@silverpill Yes, same permission scopes as well I think.


Phantasm@phnt@fluffytail.org (2026-05-26 04:07:31)
1-800-PLEROMA
Pleroma tech support, how can I help you today?


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 @feld@friedcheese.us
Phantasm@phnt@fluffytail.org (2026-05-24 04:24:51)
@feld @lain 
@silverpill partially solved this I think with minimitra by turning Mitra into a proxy/gateway (probably already used for the nomadic activity shenanigans). A client stores posts locally and sends them off when it comes online to the proxy that handles the rest.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-05-21 05:24:49)
@silverpill @tadano @mischievoustomato You can also publish the deb package to the Gitea Debian package registry, if that wasn't removed on Codeberg. So users can add the registry as a repository and get updates via system updates as well.


Phantasm@phnt@fluffytail.org (2026-05-17 20:04:53)
>Having some experience implementing JSON-LD processor and encountering issues that many users face, I wanted to share some thoughts on potential directions for a lightweight alternative.
>encountering issues

:puniko_laugh:


Reply to @phnt@fluffytail.org
Phantasm@phnt@fluffytail.org (2026-05-04 17:36:00)
@silverpill Basically the way I see it is another round of reinventing a perfectly functional wheel once again.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-05-04 17:09:56)
@silverpill It's just more stuff nobody wanted and nobody will implement. Emelia is correct in sticking to RFC, but the issue is that there has to be a really good reason to implement two separate authentication mechanisms and C2S isn't a compelling argument. I'm not annoyed by which OAuth version to choose, or what new scopes to make, or what page long flow chart the flow will required. This shouldn't exist at all.

Stick the OAuth endpoints of your server software into the Actor under "endpoints", talk MastoAPI scopes to them and be done with it. If you are implementing a fedi app, chances are high you are working with MastoAPI already in some way (unless you are doing Misskey), introducing a completely new mechanism for authentication is a recipe for disaster.


Phantasm@phnt@fluffytail.org (2026-05-04 16:23:45)
>We will end up with an OAuth profile for ActivityPub, but it'll probably just be mostly identical to the OAuth profile from AT Protocol.

Literally nobody cares. Nobody asked. Nobody is implementing this shitshow: https://github.com/swicg/activitypub-api/issues/1#issuecomment-3708524521
We solved the issue a long time ago.
image.png

RT: https://activitypub.space/post/1839
---Attachments---
image: https://upload.fluffytail.org/media/a2/3d/b6/a23db6e43b3dd885e23ddf22aa065f34fbc68f0b7a806eeadc73b42eab84ab26.png?name=image.png


Reply to @feld@friedcheese.us
Phantasm@phnt@fluffytail.org (2026-05-02 05:23:10)
@feld @lain It's a W3C requirement, W3C needs the copyright ownership and patent freedom to ensure it can stay an open spec, still dumb nonetheless (especially the simping for W3C part).


Reply to @lain@lain.com
Phantasm@phnt@fluffytail.org (2026-05-02 05:16:30)
@lain This is like the third time this came up. Previously they also wanted everyone to sign some CLA giving W3C copyright ownership in FEPs or SocialWG. Don't remember the specifics anymore.


Phantasm@phnt@fluffytail.org (2026-05-02 05:10:03)
Lol, lmao even.
image.png
---Attachments---
image: https://upload.fluffytail.org/media/9b/7d/92/9b7d92fa921a71b14bb05bbbcc0cb980acfc927f91d7e51c86dee870f2033a03.png?name=image.png


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-04-26 05:12:07)
@silverpill There have been a few of those over the years, yes. Mostly during the whole nazi Pleroma and Hitler Tusky time. With Mitra it's mostly because you support Monero and crypto in general. I've seen people mass block Mitra instances, because they saw you could login with crypto on public.mitra.social.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-04-26 04:45:42)
@silverpill GTS user having a normal one, I've seen many requests to add software-based federation policies into GTS and also Mastodon.

There's also an easy Mitra instances blocklist if you modify Fedilist csv responses slightly, but don't tell anyone 🤫


Reply to @verita84@poster.place
Phantasm@phnt@fluffytail.org (2026-04-22 00:11:22)
@verita84 @sneeden Can't wait until the centralized crypto meme token idiots fall for pumps again.
exit-pump-your-are-going-to-die.png
respect-the-pump.mp4
---Attachments---
image: https://upload.fluffytail.org/media/d7/7c/b9/d77cb91b63d4d9db3dcf0a1a0f8774bb0d84aaa21caec595ea0a1cfbbf609235.png?name=exit-pump-your-are-going-to-die.png
video: https://upload.fluffytail.org/media/30/51/33/3051333262805f2d34a240c18ab5580b0b6509e3c5bd94588461d4d05de8a60a.mp4?name=respect-the-pump.mp4


Phantasm@phnt@fluffytail.org (2026-04-21 23:51:20)
Get your slopped fedi posts today.

RT: https://poster.place/notes/alcau3ph26u20005


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-04-18 16:56:12)
@silverpill @p Doesn't surprise me Evan was involved in that once again. But Gleason actually figured something usable years prior to that with the NSFW MRF. You could easily host an API server and use some local selfhosted model for detection.


Reply to @silverpill@mitra.social
Phantasm@phnt@fluffytail.org (2026-04-15 01:38:56)
@silverpill @feld @benpate Because the way Matrix does it is kinda flawed and makes inserting malicious devices easy-ish. OMEMO is the second extreme they can go to. 

This ActivityPub becoming a kitchen sink protocol is getting really weird. First it was trying to make C2S usable and now E2EE barely anybody asked for. When are we going to get emoji reactions standardized?

Older Notes