tangled.org
Currently, if you change your handle and access a repository with the old handle in the URL, you'll get a 404 error. This could break various things (for example, git push/pull won't be able to resolve the repository anymore until the local repo's remote link is updated). There should be a way to check whether a handle is actually able to resolve to a DID, and if so redirect to either the new handle or the DID.
Monorepo for Tangled — https://tangled.org
feat: track handle changes for link redirection #130
closed
opened by
hexmani.ac
nel.pet
oppi.li
agree with nelind here:
- if you access to a domain or transfer that over to somebody else, the tangled appview cannot redirect old handles to the new one. it could result in folks squatting handles
- code that is dependent on tangled URLs should ideally use DIDs and we should do a better job of exposing this to end users
- presently, the atproto spec suggests to ignore non-primary handles in the DID doc, which is why we do not support more than 1 handle per DID:
The current handle for the DID is found in the alsoKnownAs array. Each element of this array is a URI. Handles will have the URI scheme at://, followed by the handle, with no path or other URI parts. The current primary handle is the first valid handle URI found in the ordered list. Any other handle URIs should be ignored
this could be cool to have for users that own more than 1 handle (tangled could redirect to the primary handle).
I would be concerned about how this would interact with the fact that a handle can be changed not only to no longer point to an account it used to point to but to point to another account as well. Without thought put into how to invalidate that you will end up with a handle that just doesn't do it's job. Even if you figure out a way to properly invalidate for that situation you now have a situation where a configured remote suddenly changes underneath the feet of users without them knowing. Implementation wise this cache/tracking would also have to be implemented at least knot side and probably both on the knot and the appview. Some knot admins might not want to deal with that even if its implemented knot side to only track handles of members of that knot.
I think the cleaner solution here is either for tangled to entirely abandon using handle based URLs by default (such URLs are fragile by design after all) or at least change any URLs that are expected to be copied out of the UI and used and relied on over time (such a git remote URLs) to use DIDs instead of handles.
As a "workaround" of sorts tangled already supports DID based URLs so you can for now rely on manually exchanging handles for DIDs in URLs. This works for both browser URLs and git remote URLs.