@dansup When threads accounts interact with Pixelfed accounts, is there data leakage?
How can I protect my data or how can I prevent Meta from profiting from my activities?
@peloria In the next release you will have the ability to block any server domain, like threads.net, this will prevent them from being able to view your data
@graue@dansup yea, I'm going to either close my account or change instances if pixelfed.social is going to help meta 'embrace extend and extinguish' the fediverse.
@nathanu I'm not sure I'm gonna go that far, but I am disappointed, and would appreciate some transparency as to what changed @dansup's mind, and if there's a possibility of reconsidering based on Facebook's lax moderation practices toward bigoted content.
@graue@nathanu I publicly stated 6 months ago that I will give them an opportunity and if they violate our rules we will act accordingly and de-federate.
@dansup Thanks for clarifying. I definitely do remember you creating a list on FediDb.org of all the servers that had signed the FediPact, and pixelfed.social being one of the biggest servers on that list. The pact says, "i hereby agree to block any instances owned by meta should they pop up on the fediverse." https://fedipact.online/
So this is a change of position, and one I personally don't agree with, but that is your prerogative. @nathanu
@dansup Absolutely wild! Though it's kinda jarring to have the usernames end in @/www.threads.net and I hope they make it just threads.net in the future.
Did Federation just work through the power of friendship and ActivityPub? Or did you have to do any extra work to make the connections go? Of you learned any lessons in getting this to interop, it would be amazing to hear what you did.
@dansup Thats awesome news. Thank you for this info.
Hopefully it means that there’s not a “Threads dialect” of ActivityPub, and if I can communicate with PixelFed I shouldn’t be too far away from talking to Threads, too.
> that, and they don't even have /.well-known/host-meta set up to properly redirect it.
I don't think www will cause problems, their webfinger works, request to https://threads.net/.well-known/webfinger?resource=acct:mosseri@threads.net returns {"subject":"acct:mosseri@threads.net","links":[{"href":"https://www.threads.net/ap/users/mosseri/","rel":"self","type":"application/activity+json"}]}
WebFinger lets us take an ID like name@domain.example and get an actor endpoint https://domain.example/some/path/to/idnumber.jsonld . The format of the actor endpoint is implementation-dependent, so the WebFinger lets us have a nice little ID that is easily recognizable.
@grishka The problem (?) is that I could configure my WebFinger server to point to someone else's actor endpoint, which would be misleading. So if evan@domain.example points to https://whitehouse.example/users/potus, it would make it seem like evan@domain.example is the right shortcut for getting to the President of the United States's ActivityPub endpoint. (It will happen.) It's not that big a deal, but it's a little bit of a problem.
@grishka What we need is a way for the AP descriptor to say, "these are valid Webfinger strings to use for this account." There's not a way to do that in the AP standard (yet; I'm going to start working on a FEP for it).
@grishka The way Mastodon hacked around this, and other implementations have copied, was by taking another element of the actor, preferredUsername, and the domain part of the actor endpoint, and making a Webfinger id out of those two. So, in the above example, it'd make a Webfinger ID out of potus@whitehouse.example.
@grishka It then does the Webfinger lookup again with that new Webfinger ID, and checks that it points to the right Actor endpoint. It then stores this webfinger ID as the right one to use for this actor from now on.
@grishka So, the problem I'm seeing with threads is that its webfinger IDs are on the threads.net domain, like mosseri@threads.net. But the actor endpoints are on the www.threads.net.net domain (I typed that out because threads keeps eliding out the www.threads.nete services are going through the dance I described above, and ending up with "corrected" Webfinger IDs like mosseri@www.threads.net.
Most activitypub implementations rely on webfinger anyway and I see that threads.net's webfinger solves the problem by returning proper URI even if I mistakely request mosseri@www.threads.net.
But www subdomain is desirable for cookies isolation in cases when site has multiple other subdomains for different purposes.
Add comment