@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.
Top-level
@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. 3 comments
@grishka In general, we just want to use the bare domain name if at all possible, at least for the actor endpoint. 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 But www subdomain is desirable for cookies isolation in cases when site has multiple other subdomains for different purposes. |
@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 dot threads.net domain (I typed that out because threads keeps eliding out the www), so all the services are going through the dance I described above, and ending up with "corrected" Webfinger IDs like mosseri@www.threads.net.