Resolve discrepancy and misconception between expected and actual use of the framework

[jlvandenhout]

Several questions arose in the IOTA community due to a discrepancy between expected and actual behavior of the IOTA Streams libraries. Also the distinction between what is part of the framework and what is part of applications of the framework seems to be not well understood at the moment. To obtain better insight we could ask questions like:

• What did you think was a use case for Streams and why did it not work in your case?
• What utility did you think was provided by the framework but turned out not to be?

[jlvandenhout]

In the Streams Channels application there is a masked payload field. The overall understanding of this field is that it can only be read by a participant who knows how to find the channel, however when inspecting the actual messages in the Tangle, this field does not seem to be encrypted by default.

[jlvandenhout]

Announcing an already existing channel in the Streams Channels application currently results in an error when a new participant tries to handle the announcement. Maybe it is an idea to let this fail earlier, when the author tries to announce the channel multiple times, or even prevent this by checking for an existing announcement message.

[DyrellC]

This is already a thing in the develop branch actually. If a user tries to start a channel and the announcement already exists it will return a ChannelDuplication Error.

streams/iota-streams-app-channels/src/api/tangle/user.rs

Line 298 in 4e3a2c8

try_or!(

[jlvandenhout]

There is a discrepancy between how the public payload is expected to work and how it actually works. Some users expect the public payload to be always accessible, even after a keyload when a participant is not subscribed. In the actual application, messages can only be found if a participant has the correct keys to find the next message, so keyloads in this sense have nothing to do with the payload of a message. Maybe it is an idea to make more clear what is needed to find next messages in a stream versus actually accessing message contents?

[jlvandenhout]

Currently the Streams Channels application is integrated in the Streams repository, which makes sense from an organizational perspective. However, as most users at the moment have a use case for Streams Channels, it is not immediately clear that Streams Channels actually is a protocol built using the Streams framework and that other protocols can be built using that framework. It became clear in multiple discussions on Discord that this the distinction between what is the framework and what is an application of the framework should be more clear. Maybe it is an idea to separate the framework from its use cases (i.e. Streams from Stream Channels in the repository) at least in the documentation (currently Streams and Streams Channels are described in the same document) and maybe also on the repository level?

[kwek20]

Sorry @jlvandenhout Well get to the questions soon! Both Dyrell and I just have a huge backlog of other tasks for chrysalis atm :)

[jlvandenhout]

No need to apologize! Just wanted to create a place to gather these questions as on Discord they get asked more often, but get lost in the chat. Probably most of the misunderstandings can be resolved by ourselves by just reading the docs a bit more thoroughly ;)