Virtual Hologram implementation: minting should automatically insert the Virtual Hologram using a steganographic method
Spectral Attestation implementation: extract the Virtual Hologram and validate it using on-chain data
s y r i u s and other compatible wallets should support registering and transferring NFTs with multiple formats. For example, the s y r i u s wallet should support a simple and intuitive Drag & Drop functionality to mint an NFT or a collection of NFTs
What actual steps or development activities can we extrapolate out of these points?
One first step would be to actually define a standard.
If you want to embed data and go by the idea of the article (it mentions things like smart contracts, hd videos) you have to agree what kind of data you want to allow as nftâd object. Then you have to check what kind of data you are able to embed there and how that would be realized from a technical standpoint. Then you would have to decide; do you want to allow one basic set of embeddable data? That would mean you agree on a subset that is supported by all data types you want to allow to be nftâd. E.g. embedding a hd video in a jpeg wonât be possible I guess for physical reasons.
Else you could say that only certain types are compatible with each other.
In parallel another group could look at how token minting can be realized, how the insertion of holographic data would work and how this data later would be validated.
With both tasks finished you could begin to define the minting standard, which would have to incorporate the results from both groups, so that a link exists between the minting and the insertion of data. Both steps are meaningless without the other.
Hopefully that wouldnât require a change to the network code or even smart contracts. I think it would, as no standard is meaningful when itâs not validated somewhere, and that is probably not a task that should be left to the wallet builder. If it wouldnât, at that point you could begin to implement the standard on syrius or elsewhere.
Thatâs a very rough description of the process as I would see it now.
so it seems a WASM SC mechanism is paramount on all fronts. In your opinion @devs is this achievable with a small group? Do we need to look more broadly for developers to assist with this or bring certain key skillsets in?
Try to gauge interest first, see if we can get any of them to bite.
Then funding wise, yeah we could have ~25k at current price to fund a Dev - would that be enough though? Even if it were to work as part of a team with yourself or others, if we could break down the work into smaller deliverables it could work well
We could front up money to start via community donations Iâm sure of it
Ok I have two thoughts on that.
First is that I donât think that you can hier external devs with znn at this point; so we donât necessarily would have to pay everything upfront but it would have to be dollars or something easily convertible.
Second is that I donât oppose the idea of outsourcing implementation, but I would prefer the community / us to define and specify the outcome we want to see.
So my suggestion would be to keep the idea of potentially outsourcing work in mind, maybe even ask around if the community would be willing to sponsor that or advance the payment.
But start with a group of people, sourced from the community, that are willing to commit to the task and the work in a structured and organized team effort. Do some research first to understand the task and the options we have; donât focus on wasm before we can explain the why, and how it would be integrated. Make the selection of the vm tech a transparent decision process that documents the pros, cons and hows.
Then we can decide if we have enough resources in the community to realize it, or if we have to hire externals and how. But the groundwork should be laid and decided on by the community.
At least try it that way. If it turns out that weâre unable to finish even those first steps (Iâm not sure if we have enough momentum tbh), then we can just take Kaineâs advice for wasm and use the community only as a source of the required liquidity.
Are we at that point already? Serious question.
To me the implementation of a runtime is actually quite a complicated architectural decision.
To give a few examples, which nodes run it (some or all)? How do the runtime outputs affect consensus. Is the current consensus mechanism setup correctly to take these inputs? What if the runtime produces different outputs on different nodes? How is consensus reached?
How do we ensure that the runtime is efficient and scalable? Poor implementation decisions could have ramifications down the line. For example, there are key decisions to make around runtime termination (ie a timeout if the SC hangs) which could affect the usability of the runtime and/or the stability of the network.
Economics - how does plasma interact with the runtime. Computation has a cost which is borne by nodes. Are the current plamsa tables suitable? Should we have higher and higher plasma requirements for computaqtion. For example in EVM youâll get a crazy high gas fee if you try to do something that canât be computed. On NoM, would you need really high plasma to do the same? How do you prevent a SC attack (DDoS style) without this? Imagine an attacker sending lots of impossible to compute SCs to overload the network. How do we assign increasing plasma requirements to different computational loads?
If someone or a team created a runtime as part of go-zenon, who is going to audit the code? Are the core team still the maintainers of the repo? Will the community accept the go-zenon fork to implement the runtime? What if the runtime implementation has flaws? Who will fix it? Will we roll back to the last version of go-zenon if there is a fatal flaw?
For these reasons and probably many more which I havenât thought of (not being a developer myself), the core team needs to be heavily involved in the SC runtime implementation for it to have a good chance of success.
Very good summary.
I only donât agree with the last paragraph.
Should the core team appear to contribute, I would welcome it more than anything. But I doubt that they will; we should not make any of their possible actions requirements for our own.
We have the mechanisms in place to let the community (or at least a subset of it, represented by pillars) decide.
Say we push a well-defined initiative to implement a vm through az successfully. Ideally this initiative would constantly receive support or feedback from the team and/or Kaine. But it might not. When finished, ideally the team/Kaine would pull it into the code. But they might not. Then at that point we would still know that a fork incorporating the vm has the required community support, and that is all whatâs needed.
Regarding audits and the communitiesâ ability to decide if the implementation is any good. They canât, they donât have that ability. No one has, not even the most competent devs among us would be able to validate a project of that complexity in a reasonable time span.
And thatâs why any successful initiative would also have to enable everyone to do so as best as possible. That can be done:
Solid documentation of the complete process, all the complications, complexities, risks and problems, and the steps taken to solve/handle/minimize/prevent them, generates the required trust.
Still not everyone will be able to understand everything, but if itâs good enough to enable the trust that some can, itâs good enough. Additionally, some parts can probably be audited externally.
Shouldnât we pressure the core team into priortizing
the development WASM runtime? At least weâd have a solid foundation for SC development otherwise who knows how many hacks and issues weâll have to solve until we got a sustainable implementationâŚ
As a non dev this seems like a huge bottleneck as far as I can tell and the core team should take the lead here imo. Maybe we xan comvince them to do so.
So I would suggest then we develop some specific tasks we would like to achieve, and then ask MrK for his involvement. Do we have the skills/knowledge to develop a high level plan as if we were to fork the code? I feel the core devs would be open to collaboration if we bring something to the table
âA teamâ could still be the core team. So if the community votes on them being the ones to implement WASM theyâll do it. We just have to set up an orderly voting procedure. @0x3639 can we do polls in this forum with signed wallet txs?
