Post #31763

Signature verified

The signature from the blockchain entry has been verified against an identity on this server.

The entry content as it exists in the database. This should be verified against the blockchain entry.
[Sphereon BV] Niels Klomp
Sorry for the long posts. I want to provide a bit of background first in this post before continuing to really answering your question in the next post.

The visible application is something we have to collectively decide upon with people that want to put in the work. It will probably also be driven to a certain extent by the outcomes of the first phases described above. The problem with the protocol is that it sells we can do everything with data. Everybody knows the saying "Jack of all trades, master of none" I guess.

If we do data why don't we have very clear use cases and products for the protol? Why don't we have lower level stuff like:
[*]Schema's and validation built in
[*]Private chains and/or authorization
[*]Indexing of data
[*]External blob/file storage integration
[*]Private/public and/or Permissioned/Permissionless integration of Factom networks
[*]Specs and reference implementations/libraries for interoperability across certain use cases
[*]Making signatures first class citizens in the data layer, as almost every implementation on top needs them and has to reinvent the wheel
We expect everyone to use protocol but [B]figure out themselves[/B] what to do with the protocol without providing real examples. I find it interesting that even people in our community have a hard time figuring out products or use cases themselves or who don't get much further than only the standard Proof of Existence (not saying that doesn't have merit to be clear) with files. For me it boils down to a combination of a lack of imagination and deep knowledge of the technology.

I think nobody can blame people if we don't provide examples. If people in our community cannot even come with proper use cases and ideas, why do we expect external parties to figure it out by themselves and come running to us?

We are working mostly in silos, mostly in small 1, 2 or maybe 3 person teams. Most of it commercial and with a lot of overlap, and some feel competition. I already explained before that it really doesn't make sense to have something like 4 or more different DID implementations, since DIDs are already an abstraction layer where you access Identities through the universal resolver and registrar APIs. You really only need [B]one of these[/B] to make it work, yet we have multiple parties working on the tech. Sphereon is part of the Decentralized Identity Foundation and already provided the registrar and driver. It simply is a waste or resources we could direct at more collaboratively defined goals using the tech instead of creating it.

For this to change we need to come up or work out [B]2nd layer use case, example product ideas, and specifications[/B]. We need to [B]align core development[/B] with [B]2nd layer applications[/B], so they can [B]reinforce [/B]each other. It means ensuring we come up with specs, deliverables and requests for proposals first, instead of everyone working in their own island and then submitting a grant proposal that suits them. Then we need to work together on developing these low level 2nd layer libraries, specs and APIs. That is exactly how Sphereon works with all kinds of partners. We work with you for Off-Blocks, digital signatures and identities on blockchain in accelerators/infra calls like the European Self Sovereign Identity Framework (Business call), Japan accelerator program. We work with Konkuk University in South Korea, a Dutch non-profit and schools for educational credentials like diploma's and competencies. We work with 2 external partners on providing digital identities to special investigators. We work with several partners on providing company passports to Dutch companies on different ledgers. I can go on about more projects we do. Point is that we believe in co-creation, as it brings collective networks together, it brings knowledge together and it allows to focus on what is really needed for different stakeholders.

I want something similar for the protocol to happen. To setup clear use cases, set up specifications for these use cases and setup reference libraries/implementations, whilst at the same time aligning these 2nd layer use cases with core development. It is rather odd we have already identified the need for ECDSA (Ethereum) signature/key support something like 2 years ago for different use cases on FAT/Factom, yet we still don't have it. These are things we need to act on. We can have multiple parties sort of competing with each other on commercial products (I don't regard it as that, I know some do), but instead of waiting and hoping that if some entity becomes successful and than also return the favor to the protocol, it makes more sense to ensure the [B]fundamentals [/B]are worked on [B]together[/B], so people can create better products and products that can work together or reinforce each other.

Although not wanting to make this political, as I am not even a fan of the person, but [B]"let's put the protocol first!"[/B]
This is the raw content, without BBCode parsing.