Reset instance data based on heuristics #315

Open
opened 2022-11-26 20:09:25 +00:00 by luna · 0 comments
Contributor

This is a spinoff issue from discussions that happened in #304 and the suggestion made in #312.

I think that is a higher level thing (resetting instance state on new instance actor key) which is separate from the changes relevant to this one.

Practically the reachable state of an instance is already reset if it goes dead for a couple of years and then comes back online with a new instance public key, however, that wouldn't be true for the has_request_signatures field I cooked up in the aforementioned issue and PR. At the moment, it will stay true if it was set true before.

We would be treating new instance actor keys as a new instance entirely, and if we update the keys, all fields get reset (for now, it would just be the single boolean flag, but if we come up with new instance statistics, I think they would fall down on this kind of problem sooner or later).

A possible compromise that would be less complex would be to reset the fields on unreachable -> reachable state transitions (so we would be saying that in a period of unreachability for 7 days IIRC, the instance would need to prove its properties all over again, I'd be okay with that).

This is a spinoff issue from discussions that happened in https://akkoma.dev/AkkomaGang/akkoma/issues/304 and the suggestion made in https://akkoma.dev/AkkomaGang/akkoma/pulls/312. > I think that is a higher level thing (resetting instance state on new instance actor key) which is separate from the changes relevant to this one. Practically the reachable state of an instance is already reset if it goes dead for a couple of years and then comes back online with a new instance public key, however, that wouldn't be true for the `has_request_signatures` field I cooked up in the aforementioned issue and PR. At the moment, it will stay true if it was set true before. We would be treating new instance actor keys as a new instance entirely, and if we update the keys, all fields get reset (for now, it would just be the single boolean flag, but if we come up with new instance statistics, I think they would fall down on this kind of problem sooner or later). A possible compromise that would be less complex would be to reset the fields on `unreachable -> reachable` state transitions (so we would be saying that in a period of unreachability for 7 days IIRC, the instance would need to prove its properties all over again, I'd be okay with that).
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#315
No description provided.