If a user has moved, and some new user registers on the old pod with the same name as the previous user had, then it could be possible, that somebody will try to discover the old person by the handle or even send a message
We could add a recommendation to the spec that old local usernames are reserved permanently - that would make sense since that is what happens when an account is deleted in diaspora afaik (though would have to check to make sure). I’ve made an issue.
But really, the keys will have been regenerated so there isn’t really a possibility of hijacking an identity like this.
It is theoretically possible, that somewhere exists a pod, which has discovered a person, but the new pod didn’t know about that pod, so “I’ve moved” message wasn’t sent to it. In this case discovery with webfinger could return 302 code and “I’ve moved” message as a body so that the pod could process this message instantly.
You mean store the whole “I’ve moved” message payload on the old pod and respond to webfinger queries made towards the old closed identity. That sounds good otherwise but to make it work webfinger would have to pick up the message as a response. I think that might be a bit outside spec?
3 and 4 relate to 1 - where I think we should just recommend reserving forever.
TODO: To avoid an extra endpoint, should we use a version of NodeInfo instead?
@jhass had strong objection against it, so probably his opinion is to be considered.
Well, I didn’t mean the NodeInfo but a NodeInfo But, I think it is out of scope of this spec anyway, better keep it simple with a dedicated clean endpoint.
I guess it’s fine if I base the content schema on this?
Yes, but generalized for the spec, so we shouldn’t include all the keys but a generic set. diaspora* can of course implement a larger set containing the full amount of data used in our profiles.