Seperate FIP and FIS or recombine

Seperate FIP and FIS or only one FIP?

  • Total voters
  • Poll closed .
Hi All,
Currently we have 2 seperate proposal/specification systems. FIP (Factom Improvement Proposals) and FIS (Factom Interoperability Specification). FIS is a spinoff of FIP and designed for 2nd layer solutions, where implementers are mostly external parties that want to have an interoperable solution on top of the Factom Protocol. Some examples of what will/could become a FIS:
  • Signing data using DID identities
  • Verifiable Credentials implementation
  • On-chain voting
So FIS is all about voluntary 2nd layer interoperability between products and solutions. Basically a set of best practices and designs how to solve it (not the actual implementation itself perse)

FIP is for core development, factomd/walletd APIs and language drivers (clients). Although it is also not enforced a FIP will typically end up in the protocol itself. Some example FIPs that are in the works:
  • New P2P layer in factomd
  • New configuration subsystem in factomd
  • Sharding design
These are not so much of interest to external parties, as it relates to the core of the protocol. Of course if we get multiple implementations in the future that might change a little, but still the clientele for that is different from the clientele wanting to use the protocol for solutions/products on top.

The separation has been created with the above in mind, but some people mentioned they want 1 system, where the separation is basically made by tagging it within the FIP itself and putting them in separate buckets. Although I think it makes sense to have them separated given the different audiences and purposes (specification/interoperability for FIS vs shared design and implementation for core for FIP), I am happy to merge them back together if people feel that is the way forward.

Please provide your input in this thread if you have any.
Last edited:
Hi, I'm one of those people who want one system and also volunteered to be a FIP/FIS editor. The main reason I prefer one system is to make it easier to manage and find them. One of the challenges of decentralized communities is that it can often be hard to find all relevant information in one place and having to manage two separate github repos for what is essentially the same process seems like an unnecessary separation, especially because there are going to be hybrid proposals.

For example, DIDs at the moment is a pure second layer spec but over time might be adopted by core-code such as staking or server identities. A single system would make hybrids a lot easier to manage.

The way I envision the system is a single github repo with a README that consists of two separate tables, one for FIPs and one for FISs. Also please note that I care more about the two of them being in the same repo than I care about the two of them having the same identifier. If the majority want to separate FIPs and FISs, I would still prefer having them in the same repo.
Yeah, but that is because you are involved with both. Turn the perspective around. We are creating core for others to use. For them it really makes no sense to weed through how we restructured P2P or config in factomd.

They want to make sure their products and solutions can work with others parties products and solutions. You want to have that all in one place.

We want to be the platform for others to build upon using best practices and with interoperability in mind. Don't clutter that with core stuff IMO
Thanks for bringing this up, Niels. I am in agreement with Who's points here. I think overall there will be less confusion with a single system, and we can focus the limited developer attention in one spot. I don't think it makes things any more cluttered --- Bitcoin and Ethereum both use a single system and navigation seems pretty intuitive ( In the future we'll likely have issues that are non-core but also not about interoperability, like ethereum's "meta" category about governance/philosophical related proposals

I think separate systems also introduce some unwanted gray area. For instance, you list walletd and client libraries as "core" but they don't actually affect the protocol at all. They're just second layer tools that make interfacing with the base protocol easier. Wouldn't those be more of an interoperability thing, so that applications can inter-operate using the same wallet tooling?

Maybe it makes sense to have FIP/FIS merged into a single FIP system, but have two editor groups: one for core and one for non-core?
I have been convinced by the arguments in favour of a single repo. I would not be opposed to separating them into two different tables within that repo, though that still leaves some open questions about how to categorise certain proposals.

As for making things easy to find for outside devs, I would say that this should be addressed by ensuring a full and accurate title/description for each. People are more likely to search for keywords than browse an entire list of specifications for anything that might apply to them. I am not concerned that the presence of FIPs in the same list as FISs will make relevant items too difficult to find.
I'm leaning towards the unified approach, but with separate editors for the core related changes and for 2nd layer solutions. I understand the rationale behind having them split, however, I believe a clear separation between the two is more a matter of presentation and doesn't necessitate the introduction of two different "tracks".

I'm no expert on FAT, but I believe as a second layer solution, the existing FATIPS should be merged into FIP/FIS and editors for FATIPS should also become editors for FIP/FIS.
I'm not involved with FAT in any way, but it seems like its a project with its own self-contained governance system that suits its needs well enough already. I don't think we should impose the FIP system on FAT if that community of devs doesn't think its necessary. At the end of the day, a project's maintainers get to choose what style of governance they want
I definitely agree that there is a reasonable distinction to be made here, particularly when you look at what groups of people need to come to a consensus about a given proposal. Proposals for the core of the Factom protocol require consensus among the maintainers of Factom implementations.

Proposals for 2nd layer protocols on top of Factom can actually be freely adopted or ignored by anyone building systems on top of Factom. It seems to me that this makes the second "interoperability" set of proposals at best a set of tools and guidelines for building out blockchain products on Factom. If you want to build on Factom today, you have to do a lot of work to figure out how to design data structures that can guarantee certain things, i.e. signed entries that are not vulnerable to replay attacks.

This is what we had to do with FAT. If you want to parse FAT chains, then you are agreeing to adopt our standards, and so our FATIP system is actually delineated by "those that wish to participate in or interoperate with Factom Asset Tokens." If you were to take one of our standards, and use it in your own project with no intention to interoperate with FAT then you would have no direct reason to participate in our FATIP process.

To me the distinction has much less to do with whether the proposal describes on-chain data or lower level Factom data structures and algorithms, and really everything to do with who cares about the proposal. For example, where the Factom protocol uses on-chain data, like with identities, then that belongs in a FIP. Over time, FIS may be developed that the Factom protocol wishes to adopt, so a new FIP would still need to be started and accepted by the maintainers of Factom implementations.
Yupz. you better explained it than me. People really need to think about the outside party wanting to create a solution on top of Factom. It makes sense for me to go through a list of interoperability specifications and decide which ones I would like to adhere to in my product/solution. Knowing everything is opt-in and everything is 2nd layer.

It doesn't make sense for them to go through how factomd sharding is working internally.

This is also something we have to keep more in mind IMO. We really need to make the distinction in our target developer audience. You have core/library developers and you have what I hope is a bigger group of 2nd layer developers, wanting to develop on top of the protocol.
FIPS (Root Page)
|-- Core Protocol (Sub Page)
|-- Application Interoperability (Another Page)
|-- Governance (Another Page)
|-- Any other improvement category...

Meh, if you can't trust the audience to click the right link out of those choices to find what their looking for, I don't think you can trust them to successfully navigate to a FIS page. No one is going to be looking at a master list of all FIPs ever created. They'll never hit sharding or p2p or anything core ever. They click the category they're interested in.

Should we split New York Times into two separate papers because we have two different audiences: people concerned with American politics and people that just want to read the sunday comics?
Should we split New York Times into two separate papers because we have two different audiences: people concerned with American politics and people that just want to read the sunday comics?
That's not a good analogy here. FIPs are something that define the path forward for the Factom protocol. FIS, as I understand it, are a set of best practices for people who are using the protocol to build applications. There is no consensus required for FIS beyond general agreement among the editors that the FIS is useful and does what it claims. Beyond that users can pick and choose from a set of building blocks that have been designed and reviewed by other developers. Factom is a data agnostic protocol, and unless we are talking about a special chain that the protocol depends on, why should general building blocks be part of the FIP system?

But organize the website however is most useful to users...

Edit: fixed a sentence for clarity
Last edited:
Beyond that users can pick and choose from a set of building blocks that have been designed and reviewed by other developers.... why should general building blocks be part of the FIP system?
Because they improve Factom as a whole.

I just think we should avoid developer dilution wherever we can. We already have a core committee that never meets, and attention is spread thin . If Bitcoin and Ethereum (by far the two largest and most successful blockchain developer ecosystems) both decided to use a single system to track core, application, interoperability, or governance Improvement Proposals, I see no reason to deviate. They've been at this far longer and have seen far more traction
Yes you prove my point we do not want to think about our target audiences. That is one of my main worries for the protocol as a whole. Explain my why company X wanting to create an integration has to weed through all kinds of core related stuff? It is too idealistic to think that we will have some nice UI for this kind of stuff any time soon.

Funny thing is that the core committee is pretty active and nobody ever expressed the need for meetings till now. Attention is thin from some entities and persons yes. But overall we have discussions almost daily. If you want to do meetings we certainly can do that. I am not sure why you bring it up in this discussion though. You try to make a point out of it it seems.

And the fact that some projects made some choices in the past and became a bit bigger and then using that as the argument why it should be one thing is not the strongest IMO.
It is too idealistic to think that we will have some nice UI for this kind of stuff any time soon.
If you think the two-tables approach is too cluttered, something like this would also be easily doable in github with minimal effort: is the base repository. there's a README in there explaining the difference between layer-1 fips and second layer fips, and the info on how to write them.

core fips lead to which has a table of all core fips.
second layer fips leads to which has a table of all fiss.

Any company tasked with integrating can then be pointed directly to the specific layer's page where only relevant fips are displayed.