Lemmy.eco.br agora conversa melhor com o GoToSocial
@fediadminbr@lemmy.eco.br

Agora é possível responder tópicos ou criar novos usando uma conta em instância GoToSocial.

Antes não era possível porque o GtS tem o `authorized_fetch` sempre ativo e isso não pode ser desligado.

Já o Lemmy ganhou suporte a esse recurso há cerca de 1 ano, mas para ativar envolve um blambers no banco de dados e reiniciar os serviços.

Mas agora quem está numa instância com `authorized_fetch` ligado (GoToSocial, Mastodon, etc), pode interagir com Lemmy.eco.br sem problemas.

Obrigado @kariboka por ativar o recurso, e @andrelop por descobrir como faz!

Se você administra uma instância Lemmy e quer ativar também é só seguir esses passos e depois reiniciar os serviços:

https://github.com/LemmyNet/lemmy/issues/4451#issuecomment-1976398958

cc @fediadminbr@a.gup.pe

Is there, like, an auth_fetch readiness check tool that can be given the right permissions to do an API check of a list of known federation servers, and ask those servers if it's ready and using auth_fetch itself?

This could be a long running python script to gradually go through a large list like that, or a GitHub action? Is this even necessary at this point?

Interesting! I have threads.net blocked as an instance. @vmstan says that since we have #authorizedfetch that takes away Zucky’s easy button for gobbling up my data.

There are a few threads accounts I want to follow. I have a burner account just for those where, like a bad lover, I take but don’t give.

Interestingly enough, I can use @ivory to boost threads posts -on this account- from my burner.

Huzzah! I believe I have my cake, and am eating it too. Yay.

This server has "authorized fetch" enabled. It has been on since shortly after it became an option. Having authorized fetch enabled means many things, but perhaps most importantly, that you may block threads.net instance and they won't have access to your data. While others on the server who do want to interact with Threads users, can.

Those on instances without authorized fetch enabled don't have a choice unless the instance itself blocks threads. #TMYK #Threads #AuthorizedFetch #fediblock

#Fedify, an #ActivityPub server framework, has released version 0.7.0! Here are the key changes in this version:

• Access control for actors, collections, and more via authorized fetch (i.e., secure mode)
• Generalized object dispatcher
• Logging with #LogTape for easier debugging

https://github.com/dahlia/fedify/releases/tag/0.7.0

Welp I wrote all of this shit only to see it not get federated to the OP's instance. I think they're blocking us lol ​​

Well at least I have something to #quotepost if I need to explain (my understanding) of #AuthorizedFetch ​​

RE: https://makai.chaotic.ninja/notes/9rzkf0zr1s

@BeAware@social.beaware.live Uhh I think you've gotten it fundamentally wrong here ​​

Whether your instance's posts appear on the blocked instance or not doesn't depend on the blocked having #AuthorizedFetch, but rather your instance having AF. That instance can still fetch your posts because your instance doesn't check if the request is signed (so an instance can sign all their fetching but still not enable AF, which is what vanilla #Misskey currently does) and from which instance the fetch request is coming from (hence the "authorized").

Threads already defederates from instances that don't sign their fetching (by design because they've enabled AF), but they don't care if an instance has enabled AF (it's that instance's problem to deal with posts still appearing in Threads).

The problem (I have) with AF is that it's pretty much just #securitytheater. The documentation doesn't seem to account for this possibility, but if your adversary has enough money for some cheap domains and is well-versed in how #ActivityPub works nowadays, then it's trivial for them to forge signatures to look like their fetches come from an innocent server, therefore effectively bypassing the check and allowing the blocked to get your posts into their instance. This is already being done in the wild (with the #Soapbox developer doing this to bypass Threads' fediblock being the most infamous recently).

It also complicates AP implementations because now you have to deal with more cryptography with all that signing and verifying of requests. And signing alone does have a significant impact on performance. It's impossible to create a 100% compatible AP implementation from the spec alone without looking at Mastodon's implementation. That's where the #EmbraceExtendExtinguish or #EEE comes to play.

So overall it's the overeagerness of #MastoAdmins in adopting AF or #SecureMode without understanding the compatibility and performance implications that brought us to this mess today.

Today I'm working on putting authorized fetch (aka secure mode) into #Fedify. The protocol implementation is complete, it's just a matter of polishing the API and docs. It appears that it will be finalized sometime tomorrow. Authorized fetch will be one of the major improvements in Fedify 0.7.0.

When an #ActivityPub server implements authorized fetch (aka secure mode), how does it associate the keyId in an HTTP request with the actual actor? I know major implementations (like Mastodon) use a fragment appended to the actor IRI as a keyId, but in theory a keyId could be any IRI that seems unrelated to the actor IRI, right? Should I maintain a table of actor–keyIds somewhere in the server?

Happy to report that Kolektiva has activated authorized fetch, which will help to protect our instance's posts from surveillance and "AI" ingestion by Meta. Thank you to @subMedia @admin @moderation for defending the zone!

No, fuck you for making "Public" a gray area when it shouldn't be.

These kind of #privacy freaks and #security freaks (different from privacy-aware and privacy-conscious) who don't understand the definition of #Public.. You know, the types who will put every damn mitigation and flick on every security feature in their computer even though it adversely affects their usability and doesn't really apply to their threat model (this part is especially ignored!), and yet will do an epic #OPSEC fail elsewhere anyway... These kind of people can do a favor for the #fediverse and stay the fuck out of #socialmedia. They can come back once they understand fully the phrase "think before you click".

Don't want people using their #RSS reader against your instance? Fine, then disable it in your instance's settings. But don't expect that you can prevent everyone from still trying to use RSS against your account without your knowledge. Because that's impossible and all you're really doing here is #securitytheater. Just like what #authorizedfetch is.

RE: https://sfba.social/users/FinchHaven/statuses/111868391652688742

So, this may be because I have a single-user instance and I have fairly few 'followers', but I enabled authorized fetch on December 18th and I'm not seeing a sustained increase in CPU load. I guess I expected more computational cost?

It's either more computationally efficient than I feared or perhaps I need more boosts/replies/etc to really see a difference in load.

Can a #mastoadmin with #authorizedfetch enabled on their instance try embedding their posts in a website and let me know if it works?

Having #AuthorizedFetch enabled definitely seems to break the ability to embed your Mastodon posts on a website.

The Intentional Federation

We have recently been advocating the activation of a function which is present but usually off in Mastodon and other fedi services called Authorized Fetch. As we plead with the major development projects to take safety more seriously and make it a default, we have learned that Meta itself didn't think twice about it and has activated it in their own ActivityPub implementation against *us*.

We know this because of news that a fascist has devised a way to evade it and force federation with Threads. They promise to then turn their technique upon us and coerce unblockable federation with fascist and cryptospam instances: https://soapbox.pub/blog/threads-server-blocking/

1/7