Support for this in core Lemmy has been discussed many times. There's an open issue for it that's been gathering dust for a while. Some apps already implement this on the client side I think, not jerboa though.
In the EU companies can't scrape personally identifiable information without consent, even if it's already publicly available. IANAL, and there's probably ways they can sneak around the GDPR, but at least it's not a free for all. It's unclear though how it works for federation. It's definitely not the same legally though.
The reason for not directly federating content to Threads isn't so nobody there can ever see my amazing posts, it's so Meta can't easily profile me. Scraping public posts on a different platform would probably be illegal, at least in the EU, and reposts don't give them a lot of data about me. Federating content, however, would give them most of the same data that Mastodon has on me without even having to ask.
Mastodon instance blocks are already bidirectional AFAIK: if you block an instance your content does not get federated with them. I was actually surprised that this does not seem to be the case for Lemmy. I don't think this break any core abstraction of AP...
a long form nuanced take
interesting, however have you considered pee pee poo poo
Truly a worthy contribution to the discourse, thank you...
ActivityPub doesn't just push everything on a server to every federated instance like a fire hose. In the first place, as Masimatutu@mander.xyz said, it only feeds your content to an instance if somebody on that instance follows you, which you can set to require your manual approval. Your posts could also get pushed if somebody else boosts your post and they have followers on the other instance.
However, if you set an instance block, none of your posts get sent to the instance, period. They would have to resort to scraping. In other words, if you don't want to give meta your data, just set an instance/domain block.
For my use case yes, that would defeat the purpose, but for what it's trying to do it kinda makes sense... At least, they have to do it to comply with payment regulations. And you're still only exposing your identity to one service with a decent reputation, rather than plenty of possibly shadier ones. It seems like a fair tradeoff if what you're looking for is privacy from services you want to pay for.
Backed by who?
Andreessen Horowitz (a16z), a Silicon Valley venture capital firm with a recent history of questionable investments...
Can countermeasures be implemented in the clients to mitigate privacy risks, while not having to proxy images?
It's there... Step 4 of the section "Download A Torrent Client". I didn't call it "binding an interface" because the intended target of this post would have no idea what that means.
Other people in the thread have already made this point: even with a full mesh network, the number of remote calls made for a single activity is equal to the number of instances subscribing to that activity (plus one if the activity originates from an instance that's not the host of the activity).
A hub/spoke model doesn't change this, it just moves the load from the host instance to the hub. The number of connections is still the same: if N instances need to receive the activity, N calls will have to be made. If anything this adds 1 more call from the host instance to the hub.
Even peer-to-peer distribution of activities, mentioned by @hazelnoot@beehaw.org, wouldn't actually change the amount of calls being made. You still have N servers that have to receive the activity, so you need at least N calls overall. What this would do is redistribute the load better over instances, so the host doesn't have to make all N calls. It would definitely be an improvement, but it would not be easy to implement successfully, and it would almost surely break ActivityPub compatibility.
The only thing I can think of that would actually reduce the overall network load, though, is batching: sending multiple activities/updates together in a single message. AFAIK this is not supported by ActivityPub, though, so implementing it would mean breaking compatibility, and also implementing an entirely updated version of the protocol (which is a massive undertaking).
andscape
joined 1 year ago
Wild ass comment.
Who doesn't??? What do you do, copy 20-char randomly generated passwords manually all the time? That's the whole point of password managers...
Browsers are NOT a secure storage for sensitive data, if you want a local password manager at least please use KeePassXC.