branch announcement message type

[arnauorriols]

Description

Stream announcements communicate the stream author's identifier to the rest of the participants. Branch announcements, instead, communicate (or will need to comunicate) the topic of the new branch. Apart from that, branch announcements must be chained so that only the intended subscribers can create and read it, and more importantly, inherit the permissions to the new branch.

As a consequence of the requirements stated above, branch announcements cannot be read by anybody and cannot be the message whose Spongos keyload join (because keyloads need to be readable by anybody at any times). Therefore, keyloads should revert to joining the stream announcement spongos, and link to the tip of the branch.

DoD

• branches are created sending a message of type BranchAnnouncement
• streams are created sending a message of type StreamAnnouncement (ie rename Announcement to StreamAnnouncement)
• BranchAnnouncement messages include the topic of the new branch being created
• BranchAnnouncement messages are sent to the parent branch from which the new branch is being forked (therefore, the topic in the HDF of the BranchAnnouncement message is the parent branch)
• the cursor of the creator of the branch is increased in the parent branch (naturally, as the message is sent there)
• the publishers being tracked in the parent branch at the moment of creation of the branch are copied to the new branch, with the INIT cursor
• BranchAnnouncement message are logically linked to the last message sent in the branch, just like any other message
• Keyload messages are logically linked to the last message sent in the branch, just like any other message
• however, Keyload messages join the StreamAnnouncement spongos state instead of the linked message Spongos state

[DyrellC]

My initial thoughts are that it makes sense to have a separate announcement message for branches specifically, but considering the nested nature of the branches, I think it makes more sense for Keyload messages to link their spongos state to the BranchAnnoncement messages rather than the StreamAnnouncement. The attachment to StreamAnnouncement makes the Keyload readable for everyone in the channel, but if we intend to have BranchAnnouncement only be visible to those who had permissions to walk up the previous branches, then the same logic should apply to the Keyload messages attached above them.

[kwek20]

The point is that we dont want to need to send new keyloads for each new branch. By that logic, a keyload need to come before a topic, so it can have a link to the permissions.

[DyrellC]

That's what I'm saying though, if you have

SAnn -> [any keyloads will attach spongos to SAnn] -> BAnn1 -> K1(Sub1[r/w]) -> BAnn3 -> K3(Sub1[r]) -> BAnn5 
                                                   -> BAnn2 -> K2(Sub2[r/w]) -> BAnn4 -> SP2

Then it stands to reason that anyone who would be reading K1 would have to have access to BAnn1 first, so attaching the spongos to SAnn for readability is unnecessary, because they've already stored BAnn1. Same with K3, only people who would get far enough in the chain to read the Keyload would be those that walked up through BAnn3 to get there, so K3 linking spongos to SAnn is an accommodation that doesn't have to be made, it can link spongos to BAnn3 and still be readable by anyone who was able to reasonably walk their way up to it.

The rest of the logic makes sense to me, just not the StreamAnnouncement spongos link for Keyloads in a nested branch approach like above.

[arnauorriols]

As I think the problem here is that we are all making different assumptions about how things should work, I'll try to break down my assumptions into some premises so that we can discuss each one individually:

Requirements

1. Only subscribers with read or readwrite permissions over a parent branch can read the topic of a child branch
2. Branches inherit the permissions of the branch they fork from, at the moment they fork from, thus not needing an explicit keyload after the branch announcement
3. Any subscriber must be able to read all keyloads of the stream, no matter the level of the tree in which it is sent
4. At any point of the stream tree, a subscriber must know which is the latest message sent

Inferences

• Requirement 1) implies that BranchAnnouncements are linked to the tip of the parent branch, and that they join the spongos of the message they link to.
• Requirement 1) also needs topic in HDF should be hashed #260, which in turn needs Keyload should carry over the Topic of the branch in ciphertext #259
• Requirement 2) is also fulfilled as a consequence of the previous point
• BranchAnnouncements are not readable by subscribers that don't have access to the parent branch from which the new branch is being forked; therefore, from requirement 3) we can infere that the BranchAnnouncements spongos cannot be used as anchor for Keyloads. The only spongos that remains readable by anybody in the stream is the StreamAnnouncement's.
• The cursor of publishers ensures a sequential total order over the messages published by that user. In branches with multiple publishers however, while total order cannot be provided, partial order is guaranteed by means of message linking. To fulfill requirement 4), all messages without exception must be linked to another (except the StreamAnnouncement for obvious reasons).
• As a corollary, we can state that messages create not 1 but 2 linked trees
  • one being the explicit tree created by the links in the HDF, that determines a partial order of the messages in the stream.
  • the other being the implicit tree created by joining the spongos states in the wrapping/unwrapping of the messages, that determines the access control to the messages.
  • The dissociation of the 2 trees is necessary to ensure the stream can include new subscribers down the line. In v1.2 this dissociation is achieved implicitly by means of an external device (ie the Sequence message). In v2.0 we've made the dissociation explicit by choosing, when necessary, to join the spongos of a message other than the one to which the message is linked in the HDF.

Specific Discussion

About this diagram,

SAnn -> [any keyloads will attach spongos to SAnn] -> BAnn1 -> K1(Sub1[r/w]) -> BAnn3 -> K3(Sub1[r]) -> BAnn5 
                                                   -> BAnn2 -> K2(Sub2[r/w]) -> BAnn4 -> SP2

Note that this diagram does not depict the implementation in #236 . In this implementation, BranchAnnouncements are essentially stream announcements, and Keyloads link (both in terms of ordering and access control) to the BranchAnnouncement of the branch they forked from. Both trees are de facto the same, so the following diagram represents both of them:

SAnn  -> K1 -> M1 -> M2
      -> K2 -> M3 -> M4
BAnn1 -> M5 -> M6
      -> K3 -> M7
BAnn2 -> K4
BAnn3 -> K5

As can be seen in the diagram, #236 complies with requirement 3), but not with the rest. What I propose in this issue is the following:

• Ordering Tree

SAnn  -> K1 -> M1 -> M2 -> K2 -> M3 -> M4
                  -> BAnn1 -> M5 -> M6 -> K3 -> M7
                           -> BAnn2 -> K4
                           -> BAnn3 -> K5

• Access-Control Tree

SAnn -> K1 -> M1 -> M2
                 -> BAnn1 -> M5 -> M6
                          -> BAnn2
                          -> BAnn3
     -> K2 -> M3 -> M4
     -> K3 -> M7
     -> K4
     -> K5

[arnauorriols]

[DRAFT]

Meeting Notes

• Agreement on write permissions allowing users to create branches
• Add limit of topics that can be created in Permissions::Write (including unlimited)
• Adding a new subscriber to a bunch of sub-branches can be solved in the application layer
• Idea to have BranchCap message that admins can sent to notify the end of a branch