Factom Interoperability Specifications, request for comment

Secured
#1
As people might be aware we currently have Factom Improvement Protocols (FIPs): https://github.com/factom-protocol/FIP/blob/master/FIPS/x.md
FIPs are about core protocol proposals like sharding, P2P. Currently it is written as accommodating 2nd layer solutions as well. We had discussions about it and felt that FIPs once a approved are a bit more formal, whilst 2nd layer could never be enforced (and that is not the idea anyway)

Factom Interoperability Specifications (FIS) is the result of splitting of the 2nd layer part out of FIPs.
FIS is about creating specification for interoperability for multiple parties creating solutions on top of the protocol. It is completely up to the parties whether their software adheres to one or more FIS-es. If you adhere to it, it means your application is compatible with other products adhering to the respective FIS. Right now everybody creates their own data structures, which is bad for getting Factom as a global solutions for specific use cases.

An example. A FIS about signing data using identities (native and/or DIDs) implemented by the Off-blocks app and for instance company Y, means company Y can sign information, whilst Off-blocks could verify it, or vice-versa (or even take part in signing).

The first version of FIS is created. It by no means is clear whether we are/want to use it, but I created it so we could have a proper discussion about it.

So if people want to ask questions, suggestions and whether we want something like this, please discuss

Lastly the link to FIS ;)
https://github.com/factom-protocol/FIS/blob/master/FIS/x.md
 
Secured
#4
Just to pile on in support of Niels, Carl, and Colin above, Factom Improvement Protocols (FIP) are absolutely critical for growth - it will be these types of initiatives that will make the difference and decide the Protocol's future. I'm in full support.
 
Secured
#5
Ok I know @Alex will do a PR soon with some grammar and sentence changes (thx) and to make things a bit more clear. That will progress. So now the question is, do we want to use FIS in the future? Given the responses I am inclined to say yes.

What I am really hesitant about though is putting it up for ratification by the standing parties. FIS is meant as non enforced interoperability for which individuals should decide themselves whether they would like to adhere to it. I really like to not have this tied into governance for legal reasons (have not worked that out with the LRWG) and it is also not in the spirit of something like this.

So my suggestions is the following.
  1. We start using FIS by merrit of people creating specifications
  2. Anybody can request to become a FIS editor. It is up to the core committee to approve somebody into that role, to make sure we do not get into a situation where people with ulterior motives could become an editor.
  3. We do not put it up for ratification

Please let me know if people cannot agree with the above (or have suggestions/questions). Thx
 
Last edited:
Secured
#6
Yup, I am in full support of using FIS. It will make our ecosystem more cohesive and easier to integrate into. I also agree that there is no need to subject this to formal governance. The beauty of FIS and open source in general is that contributions are completely voluntary. No need to formalise that voluntarism into a governance document. Open source tends to work well without it and permissions can be enforced by Github rather than a governance document.
 
Secured
#7
So my suggestions is the following.
  1. We start using FIS by merrit of people creating specifications
  2. Anybody can request to become a FIS editor. It is up to the core committee to approve somebody into that role, to make sure we do not get into a situation where people with ulterior motives could become an editor.
  3. We do not put it up for ratification
I support this approach. FIS will be invaluable for 2nd layer Factom developers.