The ssb-db2 refactor is done and just waiting for changes to
ssb-db2-box2 before we can merge it and release.
Speaking of those two modules, it's nice that the refactor is done and we can focus on "actual" box2 work, which in this case is generalizing ssb-keyring so that it does key management, but allowing keys to always be passed in. This way, other modules can take care of creating or discovering the encryption keys. Our plan is to either derive the encryption keys from metafeed seeds, or to "discover" each group's keys via the invite messages. Anyway, all the keys discovered will be put in ssb-keyring, and
ssb-db2-box has to be able to control/manage ssb-keyring. Mix and I have been working on that. Mix has this PR on ssb-keyring and I have this PR on ssb-db2-box2.
In last week's team meeting we also discussed bigger picture ideas, mostly relating to design. We discussed what should happen when you join a group that contains a person whom you block. Instead of ignoring/hiding that person's content, we chose to show their content and to warn you of the presence of blocked person as soon as you join the group. Showing their content is important to preserve shared context for that group. Depending on the type of group, you might engage with the blocked person in a very different way you would on the Public side. E.g. imagine a group for a work/professional environment, where it doesn't make sense to split the conversation/context based on dislikes between people. On the other hand, on the Public side you have different expectations of who you want to engage with, you are more free to shape the context. In a sense, Groups are Context, Code of Conduct, and the maintenance of these.
One thing I learned in last meeting was that random people will not be able to see who are the members of a group. We spoke briefly about how that will happen in practice in the design of metafeeds and subfeeds.
Another thing we discussed in our team chat was a way for random people to apply to become a member of a group: we could just allow the person to start a private chat with the admins. But this would require showing to the public who the admins of any group are. Instead, Mix suggested that we just use P.O. Box, which is a way of encrypting something to a subset of the group's members (in this case, the admins). So the applicant sends a private chat message to the admins, not knowing who they are, and when the admins reply then they reveal themselves to the applicant, but they're not revealing themselves to the public. That's nice.