Priorities for the Factom Protocol

After @Niels Klomp has recommended several times to try to get alignment of priorities of the community, I thought I would get the ball going.

So the idea is this: Everyone can write up a prioritized list of things that they would like to focus development on the next 12 months. Let us focus on technical topics only and we can cover other areas in separate posts (edited from the original post, based on the discussion below). I will comb through peoples post and collect the info into a spreadsheet. This can in turn help us in the coming grant rounds. I will assign each top priority 15 points, the second 14 points and so on. If you have more than 15 ideas, you get a pat on the back for having a lot of input 😉.

I will do two counts. One for standing parties and one that includes everybody. The reason being, that only standing parties get to vote for grants. I know that standing parties might have several members, so I will count the first person who gives input as representative for that standing party.
For now, I will let others start, but I will also chime in myself. I imagine that this exercise should be given 1-2 weeks, before I pull the first edition of the spreadsheet together.

Niels’ idea was to have some kind of vote, which this also is similar to. But if a formal vote among standing parties is to be arranged, that will come at a later stage – and some standing party would have to take lead on that, I suppose.

I look forward to seeing everyone's input.
 
Last edited:
Just some random items of which some are prerequisites for items above. This is just from the top of my head. I can probably make that list twice as long. Some of these items are being worked on by us ( mainly DIDs, identities, VCs and interoperability)

  • Multisig support
  • Shorter block times
  • Other sig support, like ethereum
  • Map based data in entries instead of current list based data
  • Entry signatures as first class citizens
  • Storage separation of entries from auth nodes, allowing storage rewards, public/permissioned storage separate from the blockchain with rebalancing. Allows people to get rewards for hosting/renting data and removes storage bloat for the authset.
  • Permissioned chains
  • Identity and auth modules for non auth nodes
  • DID live support
  • VC storage/sync
  • VC verifier module
  • Linked data proofs/signatures
  • Generic open-source portal for proofs
  • Standing parties with proper DID, VC and multisig support
  • Voting and delegation based on the above
  • Factomize integration with CHAPI (VCs)
  • PegNet as proper FAT standard/integration
  • PegNet tokens from WASM
  • DAML on Factom
  • Exchange infra and dev onboarding package
  • Public CI for all components
  • Auth and identity server, client, models
  • Universal registrar for VCs
  • Mobile auth client and VC wallet
 
Last edited:
I would love to see some domain specific live feed event modules. Allowing external apps to receive domain specific events. So instead of entries, you get full DID documents pushed for instance on creation, update and deactivation. As the swagger models are there it means any external app could quite easily get DIDs pushed to their app instead of having to traverse the chains and apply all the rules etc.
 
After @Niels Klomp has recommended several times to try to get alignment of priorities of the community, I thought I would get the ball going.

So the idea is this: Everyone can write up a prioritized list of things that they would like to focus development on the next 12 months. This can both be technical and non-technical. I will comb through peoples post and collect the info into a spreadsheet. This can in turn help us in the coming grant rounds. I will assign each top priority 15 points, the second 14 points and so on. If you have more than 15 ideas, you get a pat on the back for having a lot of input 😉.

I will do two counts. One for standing parties and one that includes ieverybody. The reason being, that only standing parties get to vote for grants. I know that standing parties might have several members, so I will count the first person who gives input as representative for that standing party.
For now, I will let others start, but I will also chime in myself. I imagine that this exercise should be given 1-2 weeks, before I pull the first edition of the spreadsheet together.

Niels’ idea was to have some kind of vote, which this also is similar to. But if a formal vote among standing parties is to be arranged, that will come at a later stage – and some standing party would have to take lead on that, I suppose.

I look forward to seeing everyone's input.
I think this is a fantastic idea. It is particularly important that our efforts and investment/grants are focused on those things that are strategically important. We cannot do everything. We need to focus on the "significant few" and not the "trivial many", so prioritizing this in the manner proposed makes sense.

Technical
  • Decentralized bi-directional Factom-Ethereum Bridge
  • Significantly shorter & therefore competitive block times capable of supporting Web 3.0 & IOT
  • Standing parties with proper DID, VC and multisig support
  • Voting and delegation by standing parties based on DID, VC


Edit - Non-technical subjects removed to here https://factomize.com/forums/threads/priorities-for-the-factom-protocol-non-technical-areas.4804/ to enable this thread to focus purely on technical subjects.


Good luck with trawling through the posts!
 
Last edited:
Could we please focus on the dev priorities in this thread, otherwise this thread will once again be all over the place (and yes I get there is overlap in areas).

Bulletpoints in this thread should be convertible into FIPs
Happy to focus on "dev priorities" but that is not my understanding of "development" which as the initial post says "can both be technical and non-technical".

Given that one of the objectives is to focus the current grant round then I'd have thought that this would encompass the breadth we normally see in Grant Applications.

Perhaps @Hinamatsuri could confirm which interpretation is correct?
 
The whole idea he is following is from my suggestion to being able to create FIPs in the first place. Totally fine to create something similar for legal, marketing, governance etc. But please let's not try to tackle everything at once. That is just never gonna work in one thread.
 
My initial thinking was to get input on both technical and non-technical topics, to get a complete overview. But as pointed out, it will be a lot of ground to cover. We would also risk sliding into disucssions about whether technical development or other activities are more important. So I will update the original post and let us then stick to covering technical topics here. Then we can cover other topics in separate posts.

Eventually the priority between areas will also have to be sorted out. If nothing else, the standing parties will be forced to take a stance with voting. But to make us better prepared, let us try to have that discussion after this one, but before the next grant round in August.
 
Twelve months is a short amount of time. With development resources being thinner than usual, most of this list probably will not get done. Some of them are already under development.
  1. Multisig + ETH Sig
  2. Decentralized ANO Management
  3. Modularizing factomd post wax release
  4. Improving elections or replacing it with a different system that can recover/reset from stalls without a reboot
  5. HTTP/3 API in factomd + improved client
  6. Smart Contracts in factomd
  7. DID support at protocol level
  8. UI Tools for identity/server management
  9. A good persistent wallet + app
 
Top