# RLN <> Interrep integration (tree storage and interactions)

### Context

The idea is that InterRep and therefore it's semaphore groups serve as a global registry for allowing private membership proving - the users can prove that they are part of a reputable group without revealing their identity or pseuodoidentity.
We can use this kind of registry for some RLN related projects, as a membership permit - i.e the users part of a specific InterRep groups (we can focus on a single group or allow as many groups as wanted) can use the RLN application without performing the registration step in the RLN application. Thus the barier for entry would be the InterRep membership. Upon slashing, the users will be removed from the RLN application and they would not be able to use it anymore, but they will stay in the semaphore group.

### Storage considerations

- InterRep stores a membership merkle tree for each group (it is implemented as a one structure, but it can be seen as separate trees, because all of the operations are performed per group).
- RLN apps need to store the trees for the groups they want to permit access for. The RLN apps will need to sync their trees with the InterRep trees in order to keep their state up to date.

### Tree syncing
- The RLN trees can be synced by using the provided Subgraph for the InterRep groups and also by listening to `NewRootHash` events from the `InterRepGroups` contract, for providing more accurate performance. This can also be done just by long-polling the subgraph.

### RLN Tree updates
- The RLN trees are updated when new identity commitments are added to the accepted semaphore groups at the InterRep service, and when a member is slashed.
- When a member is slashed, the value of the leaf index for that member is zeroed out and a merkle tree update is performed on the RLN tree for the group in which the banned user was part of - no tree updates are performed on the InterRep semaphore groups.

### Membership proof obtaining and updating

- The InterRep registered users will need to obtain their membership proof (witness) for using the RLN application from the RLN application server. They cannot obtain a witness from the InterRep server because the RLN trees might be modified (i.e user slashing).
- The RLN application server can expose websocket endpoints to which the users can subscribe to and listen for registration/slashing events. This will serve as a signal to the users to know the status of their witness - upon the next RLN app interaction, they will know if they should update their witness or not.

### Conclusion

This design allows for the user registrations to be avoided on the RLN applications. This allows for better user experience and less requirements for the users (i.e if the are registered to InterRep, they can use the RLN without any additional requirements).

However the tree for the group/groups must be kept on the RLN app side, in order for slashing to be performed for the specific RLN app.