You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current specifications are (intentionally) very bare-bones and I agree that something like this is missing. The whole registration process and capability selection probably need some love so that both parties are always in sync with each other. Similarly we will need a way to "properly" disconnect two parties and maybe even some specification about how to handle failure modes (e.g. short-term vs. long-term connectivity issues).
Besides what was mentioned in the discussion above, the following occurred to me when implementing the current specs:
The last step in the registration process happens on the fediverse server. FASP do not know if the connection attempt was accepted or declined. This is not strictly necessary for the system as a whole to work and since fake registrations are a vector for SPAM, we might not want to announce when it is declined. Still, it feels like something is missing here.
Similarly, when a fediverse admin selects capabilities, this is not currently communicated to the FASP. It might be nice to know this, but again not strictly necessary.
There is no defined way to sever the relationship "properly". FASP might stop serving fediverse servers and fediverse servers might stop using FASP. It would be nice for the other party to know when this happens.
The text was updated successfully, but these errors were encountered:
From #36 (comment)
Besides what was mentioned in the discussion above, the following occurred to me when implementing the current specs:
The text was updated successfully, but these errors were encountered: