Problem: TSN Stream Standard Data Flow Diagram is missing

[outerlook]

Visualizing the information flow (where query entries are, how data is stored, how permission is stored and accessed, etc) can greatly benefit the design and discussion of #137.

cc @rsoury

[ambahk]

awesome. there shall be alignment with this parallel effort
https://github.com/truflation/truflation-transformers/issues/3#issuecomment-2082387608

[outerlook]

@ambahk

awesome. there shall be alignment with this parallel effort

I agree...

From what I know so far, and exactly as you described in https://github.com/truflation/truflation-transformers/tree/albert-wip?tab=readme-ov-file#deployment-topology

This issue should describe the steps inside the TSN system itself, how data providers would insert their data, what permission they need, and how TSN org would manage their permissions, how users would fetch, how would this data flow internally between contracts, etc.

• https://github.com/truflation/truflation-transformers/ would process data to be more easily inserted by Truflation as a Data Provider, pushing to a DB
• https://github.com/truflation/tsn-data-provider would feed our processed data to the TSN system, Truflation in the position of a Data Provider as any other, serving as an example for future data providers where we manage to feed from a simple DB (or other simple sources)

[ambahk]

I agree. There are a lot of data in the truflation-transfomers project. The discovery effort on my end will focus on breaking that up into the primitive & composed data streams, as per defined in this TSN Stream Standard.

[outerlook]

The document exploring possibilities to accommodate the latest specs requirements can be inspected already, although it can change subtly in the next few days.

https://usherlabs.notion.site/TSN-System-Contract-Architectures-and-Processes-Diagrams-9512fbebe58a46608d0a38804c16784c

What this document is NOT:

• It won't be used as documentation, it won't be maintained
• Doesn't replace the Goal: TSN Stream Standard #137 Specs document. It was actually used to create subsidies to fill the Specs with plausible implementation content and avoid creating disposable content there.

What it is:

• created to iterate and visualize alternatives, pitfalls, etc, quickly.
• created to materialize reasoning so we can explain better our choices in case its necessary

With that said, the outcome of the present document will be summarized and used to propose changes to the specs in the hope of bringing us closer to the goal.

Important parts of the document:

• Favorite Architecture Choice
• Favorite Processes Description
• Contracts Details

We won't close this issue until the Specs holds the information needed from here.

[outerlook]

Commenting in this document is allowed for any concern if needed.

[rsoury]

Note: Once on https://usherlabs.notion.site/Architectures-Exploration-ddfc93d5a2f34b789fa9ef55c5fe631e - scroll to the bottom to view the "Favorite Choice".

This choice was selected to cover all requirements in the criteria.

[outerlook]

Closing this issue as the suggestions were created

[zolotokrylin]

@outerlook did you commit the final flow/diagram to the repo? Any docs/info should be part of the repo, unless it is a marketing collateral for external audience.

[rsoury]

@zolotokrylin - It's added to the EPIC doc in #137

[zolotokrylin]

@rsoury
So this issue was a part of specing?
For future reference: if you need to add something in the Spec doc, no need to create a separate problem statements in github 🙏