for now since these are just managed groups with one manager replacing the key is fine because we are assuming an ordered message stream?
so this is the managed group check that says this peerMessage is from the groupManager peer so we trust it? if the future with hybrid groups we could get group messages from the group of members with some ACL saying trusted to relay?
the AddMemberEvent doesn't come with ACL? maybe i have to read more but how do non default ACL's propagate?
i'm a little fuzzy, would the group manager never be running on a cwtchpeer representing a person with p2p contacts and managed groups? it'll be a stand alone cwtchpeer managing a single group? (cus my next question is what if the profile is in multiple managed groups?)
it's not currently wired in anywhere except tests? where's it envisioned to be called from, ah some of the other handle events not yet handled?
it feels like some where we need a check this groupmanager hasn't already set up its one fixed name group and throw an error when being called again
(and thus an onion service per group) => (and thus a cwtch peer / onion service per group)
ah see this is what i mean, does this mean the way the experiment is compose right now it cannot be scoped to one cwtch peer? only an entire app? that's prolly a hint something in our design is a little off, and it will cause problems for clients cus our libcwtch api is bound to one app
we shouldn't need a seperate app, just two peers right? i'd actually be a little more comfortable running both of them out of the same app to make sure they cohabit nicely and peers are properly isolated etc
is this not implicit? we don't want ppl setting up peers to have to disable all new and future experiments