@Dirk @MrScottyTay Also I think that one should ask the question, what Meta could do with the data and what it is doing with the data of their users. For their users they use the usage data to present them a feed that the users appreciate. Also they use it to place ads inside of their apps. Also they use the data to serve you ads outside of their system on ad networks that use data from Meta.
All of this is technically not possible for Fediverse users.
@flancian @Dirk Threads has about 200 million monthly users, 33 million daily users. The fediverse has just under 1 million monthly users. Do you really think that 0.5% has any relevance to Meta?
Also: What data do you think Meta will be able to use - and for what? They can’t use this data to serve you ads, simply because they don’t know you. They can’t track you around the web because you don’t have a Meta account.
@cypherpunks I’ve got the feeling as if the author doesn’t know about the existence of relay servers. With them, also a single user instance works really fine, I think.
@interdimensionalmeme There are different opinions about this. And luckily people can chose networks according to their specific opinions.
@leraje @muntedcrocodile The architecture of their protocol is highly incompatible with the way ActivityPub works.
With their protocol you have got the PDS (Personal Data Storage) that stores your data. Your handle is a hostname, but normally it will not be the hostname of your PDS. In fact you can use any hostname that you have control of. Your account itself is described via the DID that will never change - and that doesn’t contain a hostname. This means that you can move between different PDS without people noticing it at all.
In ActivityPub the data storage is on the same host like your handle and your account’s URL will always point to the host where your data is located. Moving your account is by far not as smooth and highly depends on the system that you are on.
@spitz @olivier Eventually Benjamin, one of the main developers, completely rewrote the communication stack. I can remember sitting together with him at the C3 in Hamburg (not sure which year), talking about possible protocol extensions, which I then implemented in Friendica on the fly. Fun fact: With the exception of the polls, Friendica supports more parts of the Diaspora specification than Diaspora itself 😁
At that time I had the idea to abandon our own protocol (DFRN) and to completely switch to Diaspora. But there were some things (like our groups), that weren’t implemented in the protocol. Also then ActivityPub got momentum and I started the implementation. And later Friendica switched to AP as their default protocol. But we still - of course - support our own protocol and the Diaspora protocol.
@deadsuperhero Well, they have to collect this data to be able to federate. Question is only, what they are doing with this data. When they don’t block communication with European servers, they have to follow GDPR here. And these rules limit what they are allowed to do - and the fines for breaching the rules hurt even large companies.
One additional point: Most (all?) AP services perform signed requests when querying the profile and the profile related endpoints. So in the current Friendica version we already added a coding, so that unsigned requests only get some basic data that is needed for the communication, but nothing more. AFAIK some other services are doing so as well.
This coding can be extended so that signed requests from Threads will always result in only returning the basic profile data.
@Dirk How should they achieve it? The Fediverse contains of a lot of different systems that offer so much more than Threads could ever do.