Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

FASP / fediverse server connection lifecycle improvements #44

Open
oneiros opened this issue Jan 7, 2025 · 0 comments
Open

FASP / fediverse server connection lifecycle improvements #44

oneiros opened this issue Jan 7, 2025 · 0 comments

Comments

@oneiros
Copy link
Collaborator

oneiros commented Jan 7, 2025

From #36 (comment)

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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant