volentixio-blog

[volentixio-blog]

SIAN: Identity 2.0

Intro

S.I.A.N. stands for Sovereign Identity Attestation Network. This network is designed to provide users with the ability to control their identities online.

The following article creates a parallel between the physical world, and how data and identities are managed and the digital world. The overall conclusions of this article are that our digital identities, in function, do not reflect the behavior in the digital world. It is therefore theorized that changes are required in the digital world in order to better reflect the physical world in order to create a baseline architecture for our identity online.

The premise, for a system like SIAN, is that it all begins and ends at the data level. Whoever controls that data, and access to it, controls the narrative about you and your identity. The long and the short of the article is this: You should control your data online. All of it.

The Physical World

Let’s begin by looking at our day to day and how identity plays a part. Think about how you interact with the environment. To the barista, you present a version of yourself and they present a version to you. The identity you share is likely to be pretty surface stuff. At best they know your first name. A tiny piece of data. But they do not know any other data about you. Your address, government ID, passport number, or anything else of relevance about you remains with you and is not shared. You are still you, however, you are controlling the data you are leaking which ends up forming the identity presented.

Your work identity manifests, in all likelihood, more data about you than the barista identity does. Your first name, email, phone, LinkedIn, specialty, and rank are all available to the entire group, and, for the most part, this seems sensible. But your work identity is unlikely to share details about your more intimate self. Weekends with close friends. Moments alone with your spouse. The time you almost got into some real trouble. Whatever. A million things and a million things more.

Beyond these two simple identities, exist many others that all share one common aspect. You are in control of the data presented through each one of these identities. To the barista, it’s one you. To your boss, it’s another. Your friends. It’s not you being fake. It’s not dishonest. It’s not a mental issue. It's reality. It’s the way it works.

Let’s discuss the elephant in the room. People talk. You tell someone something, what’s stopping them from telling another? And so on and so on. In the real world, how people respect the data you provide them is something that remains outside of your control. It’s the element of trust you need to both shares. Sometimes that trust is broken. Sometimes it is not. In the real world, once you share something, you cannot unshare it.

Over time, humans have evolved in how they trade and form communities. In the beginning, the form remained mainly tribal. You knew everyone and everyone knew you. If you turned out to be someone who cannot be trusted, then the entire tribe, in effect your entire world, may turn their backs on you. You would be alone.

As civilization began to expand, new ways of trust needed to be developed. Away in which trade could be conducted without knowing the other party intimately. This new form of trust took the form of councils, guilds, clergy, banks, and governments. A third party that would be accountable to provide trust between two parties. A middle man. Basically, this third party would reside between two entities. Both parties trust this middle man to attest to the character, identity, and honor of the other. And in such a fashion, a business can be conducted.

Just a note. Much can be said about the current mechanics of these third-party middlemen. Without a doubt this function is required in any large scale ecosystem, however, they are not without their flaws. Centralization is the most pressing followed quickly by the behaviors driving data hoarding. In truth, both subjects are well beyond the scope of this article.

The Digital World

Now think of identity in the digital world. Who owns your identity? Certainly not you. Worse still, its federated into silos that do not share your data even if you wanted them to. Adding insult to injury, sometimes these silos do communicate between themselves, generally for profit, think ad networks, without your permission. No doubt that buried within the user agreement such a clause exists, however, for all intensive purposes we are being held at gunpoint.

So to be clear, the problem is, you do not control your data. That is the problem. Your data is how you manage your identity online. It’s those little nuggets that tell your story or at least the story you want to tell. When you are seeking employment, you know they are checking your Facebook and LinkedIn. Is that you? Do you feel that is the right way to tell your story at that moment? I don’t think so. I believe that all of us are far more complex and rich than any diluted ‘reflection’ a centralized provider can offer.

Note:

To be honest, the problem of social networks will persist for a long time to come. We are a victim of our own willingness to connect with each other. We have been exploited for profit and the whole social network thing is just going to have to play itself out. So for now, ignore the massive change that needs to take place to shift from a centralized social network into a decentralized one. Instead, I would ask you to think about other use cases such as biometric data and other emergent streams of information about you.

All this new data should be owned by you and you alone. You should be able to control what data apps have access to rather than the other way around. Developers of an application should require zero back end infrastructure because the hard part, data management, is being managed by the network itself. This alone significantly lowers the bar of entry for entrepreneurs and engineers to enter the marketplace without the longest of uphill grinds.

This small shift in computer architecture, the pivot of applications owning data to you owning the data, cannot be understated. App developers will be able to use data generated through other apps with no restrictions. You, after all, control if this new app can view this data, not the original application that generated the data. For example, if your watches biometric data gets stored in your data store, then another application developer will be able to leverage this data in order to provide a service. Simple services like heart monitors are obvious, however, other services would also be viable to construct with a small team of developers that provide advanced services for use cases such as outpatient care.

Just like the real world, the digital world will need middlemen in order to provide trust between two parties. However, just like the real world, you will also need centralized authorize to parley this trust for you. That's ok and SIAN has been architected to accommodate this scenario. For example, sometimes you must provide compliance for the region you are conducting business in, and, as a result, need attestation from the region's government. This scenario is unlikely to change for a very long time.

But let’s be honest, we all aren’t making large investments in foreign lands, we are just looking to trade online. In this case, will still require third-party middlemen to broker trust between the parties. Some cases will require a formal entity, however, other cases can be rectified in a much simpler fashion just as it is in the real world. For example, if Joe wants to work with me on something, and I don’t know Joe but my friend Susan does, and Susan trusts Joe, and I trust Susan, then I will trust Joe.

The mechanics, use cases, and functions of the trusted network continue and get pretty verbose as they go along so I will save it for another article. However, in closing, I would like to make it clear that, as with the data, you, the user, the control of your identity, also remain in full control of who you trust as a third party when conducting business. As they do not control your data, they become pluggable and can be replaced at any time for another trust verifier. As long as both parties trust the same verifier they will be able to derive trust between each other.

Conclusion

The SIAN network is a baseline protocol for people to manage their identities in a digital world. Is the underlying understanding we need to share in order to achieve true self-management of identities online. The main two facets to this protocol are:

You own your data outright

You decide what data is shared with someone else.

In an ideal world, we would also add a third protocol. That protocol would be decentralization. However, we must admit to ourselves that centralist interests will still retain control over many of our identities for the foreseeable future, and, as a result, make room for them within the architecture.

Wrapping up, we require, as a community, a system that will protect the user, their data, and their identity online based on the same principles we find in the real world. Today's centralized systems control your data and identity online in order to exploit it for their own benefits. However, moving forward we need new mechanics, tools, and techniques in order to decouple data from the applications they serve in order to ensure the user is in the driver’s seat moving forward.

Read More->https://volentix.io/en/sian-identity-2-0/

[volentixio-blog]

Vulcan: Volentix Decentralized Cloud

Vulcan is the Roman god of fire and forge. The Roman concept of the god seems to associate him to both the destructive and the fertilizing powers of fire. In the former, fire burns and is destructive, in the later, the fire has been tamed to the will of man.

Vulcan, as it is fire, is also the god of the forge.. Wikipedia defines a forge as: ‘The forge is used by the smith to heat a piece of metal to a temperature where it becomes easier to shape by forging, or to the point where work hardening no longer occurs.‘ Consider this our metaphor for Vulcan. Only our forge is the global compute infrastructure, the smith is the developer, and the metal being forged are the Dapps they are developing. Vulcan does the rest.

Decentralizing the Cloud

Today we have three players in the cloud space. Three, for an industry that is still in its infancy. Three is not a lot of choices. Three feel centralized and constrained. Three is a problem. Three concentrates power on a network that is designed to be decentralized and open. Three is a threat and we should consider it very seriously.

On the other hand, Vulcan is designed to be a decentralized cloud platform that extends the cloud services marketplace to any and all who wish to monetize on their computers. To be clear, you can deploy Vulcan onto your laptop or into a datacenter with thousands of computers.

In addition, to open up the cloud marketplace, Vulcan lowers the barriers of entry for DApp developers. Vulcan will manage the deployment, scalability, replication, security, and remuneration so that developers can spend their time developing rather than infrastructure, licensing, billing, versioning, and all the other odds and ends that are wasteful.

How The Sausage Is Made

I don’t want to get too deep into the technology, but I feel it’s important to provide a little more details that some may wish to skip. The other reason is to ‘shout out’ the primary technology we are using.

Kubernetes is the new cloud. We chose it for a million technical reasons, but most importantly we chose it for the reasons:

Its open source

The community is massive, responsive, professional, and world class

Its tenets of design are laser focused. Basically, Kubernetes knows what kubernetes is.

It's part of the Cloud Native Computing Foundation

Architecture features required for Vulcan are already native in the platform.

Security First

Vulcans primary requirement is the need to ensure security. Data center operators need to know that whatever is being deployed into their data center is isolated and controlled. DApp developers need to know that their DApps cannot change and cannot be stolen. Consumers need to know that the DApps they are using to protect their best interests and adhere to the Volentix principles.

With Kubernetes, we are able to manage security all the way through the network stack as well as isolating processes. Additionally, third parties may also create security DApps that will harden the system even more. Finally, container technology continues to improve frequently. Kubernetes, and as a result Vulcan, is already built to accommodate this! For example, VDex will not be using Docker as its container due to security issues and will be using a library operating system instead. All the technical dodads such as ingress controllers, unikernels, P2P encryption, service isolation, and flurry of other options, found deep down in the recesses of Kubernetes and its ecosystem, will automatically be deployed and managed for you…This is pretty nerdy stuff indeed…

Vulcan UI

Vulcans UI will be a ‘pluggable’ service in Verto that provides tooling to enable Vulcan operators the ability to monitor and manage the Vulcan compute instance. The tooling will support both novice and expert level operational best practices and services. In the most basic example, an operator will need to manage, when to update Vulcan (or one of its DApps) as well as,how much VTX they are getting rewarded for participating on the network. In an advanced case, the operator will require management of Vulcan at a much lower level. At this level, operators are able to, but not limited to:

View/sort/filter system logs and metrics

Create alerts

Capacity management

Whitelist/blacklist services

Note that the UI is a ‘pluggable’ service inside Verto. In this way, other services are able to create Verto UI’s for their services as well. The service provider is able to use Vertos advanced features, such as data management, and user management, to create interfaces without the need for backend services to support them. As a result, additional barriers to entry are removed from the DApp developers.

Here Comes VDex

VDex is the first DApp that will be developed for Vulcan. The reasoning is simple. We need our VDex operators to have a safe, and secure environment that is easy to use and provides them with sufficient tooling to manage their environment.

As Vulcan is deployable on a single computer all the way up to thousands of computers, so to is VDex. Things like scalability, replication, failover, throttling, and upgrading are managed by Vulcan for you. In this way, operators are able to scale their facilities easily as the network grows.

Additionally, being that Verto is ‘pluggable’, a rich UI for traders and researchers will be made available. This Verto service will provide access to the backend VDex application as well as leverage the data management in Verto.

What the Future Looks Like

The future of Vulcan is envisioned to be a complex ecosystem off DApps working in concert with each other on a decentralized cloud computing infrastructure. A global computer infrastructure in which we have decoupled ourselves from any one vendor, through decentralization, in a way that enables the democratization of the cloud.

A democratized cloud is one that supports the smallest computer needs all the way to the most advanced. A cloud in which reward is distributed fairly and more broadly. A cloud where providers can compete and users are rewarded with more and better options than they can today.

This democratized cloud, Vulcan, will also provide the ways in which contributors choose to be rewarded for their contributions. These contributors are considered to be:

Vulcan Operator: These operators will remuneration for the compute resources they provide. Once the system develops, these operators will be able to set prices and define services. For example, a desktop instance of Vulcan may be cheap since the operator provides no guarantees other than the defaults of Vulcan. In another example, the operator is managing multiple regions with multiple centers each with thousands of computers. These centers have physical security and are compliant in each region they serve. For good reason, this operator will be able to charge more for their services than the desktop operator. Regardless, both have their place in the ecosystem and both can be rewarded for their contribution to the community.

Open Source Developer: Developers should be contributed for their contributions easily using the tooling that they are familiar with already. Vulcan, through its licensing management services, which has not yet been mentioned but will be covered in another post, can attest the developers has been used somewhere, for something, on Vulcan. This means that, not only will DApp developers, or service providers, be rewarded when others use their service, the underlying open source framework developers could also gain reward. In this way, Vulcan has decentralized the development of applications while attesting to remuneration and compliance to anyone parties needs.

DApp Provider: Up until now, we have talked about the DApp developer, however, what we mean is DApp Provider. In many cases, the DApp being designed, tested, and built requires an entire team to manage. In Vulcan, DApp providers set the terms and conditions of their application to whatever meets their business model. For example, a DApp provider may have a free model and a paid model. They may have 24-hour support with an SLA, or they may have none. In short, DApp providers set the reward they want and Vulcan manages everything in between.

Wrapping Up

Vulcan is tooling that is designed to be a decentralized cloud in which Dapps can reside

Read More->https://volentix.io/en/vulcan-volentix-decentralized-cloud/

[volentixio-blog]

Verto V1 Roadmap Overview

Verto is thinking well beyond the wallet. Today’s market place is overly saturated with disparate DApps that users must install independent of each other. Going further, these DApps have no generalized architecture to support intercommunication and shared assets as resources. Verto will solve this problem at the same time that it will supply the users with the most advanced security measures coupled with data management and finishing it off with usability patterns that others can follow in order to deliver a best in class experience for the users as well as the DApp developers.

With this in mind, Verto is a platform for DApp developers (inside as well as outside the Volentix ecosystem) that will save time, resources, and money while enhancing deployment, reach to an audience, as well as security and data management. The problem we are addressing is that DApp developers are forced into developing wallets for each application they envision whenever they enter the marketplace. The activity of creating these applications is both times consuming and littered with potential risk. This method and approach result in frustration for the consumer as well as prohibitive costs for the DApp developers themselves.

Going further, when designing a wallet, DApp developers need to manage security, deployment, auto-updating as well as data management. Some do these baseline activities better than others. This results in a strong variance between teams resulting in a federated, and inconsistent approach thereby extending the potential attack vectors that, in the end, result in reflecting on the entire crypto community. In short, if one DApp gets hacked, it does not just end up causing FUD within the community but also to the general public. This ends up in the broader audience gaining consensus that crypto cannot be trusted. As we are in the inception of this industry, and we are small, and honestly not quite ready for mass adoption, it has not had the negative impact it could, however, now is the time to enhance our ecosystem so as to gain confidence in the broader community.

Verto V1 aims to provide the platform for DApp developers that enable them to produce their DApp quickly and shorten their time to market. At the same time, these DApp developers will be able to leverage the advanced features of Verto, such as data management, security, and auto-updating that ease the long term maintenance burdens these teams will face.

The community benefits from this ecosystem in that discovery of DApps and the utility those DApps provide is managed in a secure way that protects the user's anonymity and lowers the requirements on the user. In short, the users will come to trust that 3rd party DApps in Verto are secure, adhere to the principles of Verto, and have strong auditing and attestations that the product indeed says what it does without compromising security or anonymity.

In conclusion, Verto is planning for a future in which it is seen as the platform on which third-party DApp developers choose to build their products even if they are completely outside the Volentix ecosystem. Why should that matter? We believe that the user experience must come first and opening our framework in a non-commercial way benefits everyone.

Read More at->https://volentix.io/en/verto-v1-roadmap-overview/