Hi everyone!
Thatâs the raw and supposed technical specifications ideas to implement the Orivon project
Please note, thatâs subject to edits and rewrites depending on feedbacks, discoveries, and possibly better ideas
If you are new you may want to read first What is the Orivon Project
Constructive discussion is highly apprecciated
Orivon Browser Core
Orivon will be an Hard Fork of Brave, with Chromium as upstream
Futher details are still to be defined, but as right now these are the foundaments
Features
Dashboard
Default page of the Browser is replaced with an Android-like dashboard: background picture with a resizable grid where apps, links, and widgets can be placed into, some pre-inserted things may include Apps Store, Wallet management, Network, Nodes, Settings etcâŚ
Mouse scrolling will change dashboard page up to left and down to right
Deeper API access for Javascript and WebAssembly
Will be implemented all APIâs needed to allow any Web3 program/node to run on-the-fly in the Browser, starting with sandboxed filesystem, deeper network functions (allowing controlled p2p, controlled raw packeting, and more).
Programs willing to work in Orivon should compile in a modified version of WASI made for Orivon, so that needed advanced functions can be handled by browser
New APIâs will be added to chromium probably trough Blink
Thatâs considered one of the most important features of Orivon
Domain Data Ownership Confirmation (DDOC)
DDOC can be seen as an additional security layer after HTTPS, it serves to verify that the data you received are exactly what the domain owner wanted you to receive
That prevents incidents caused by remote server hacking. DDOC can be implemented for IP data gathering from an hash-table hash on domain records, or already implemented by design by protocols like IPFS
DDOC intends by design that at least the first file downloaded during the website loading, is predictable, so that the Domain Owner will declare that he wanted it to be there
Applications system
Apps can be simple DApps (Web3sites), or integrations to expand the browser compatibility and capabilities, acutally every Orivon feature is possibly backed by an App, which is potentially interchangable by user will, thus making it more free, neutral, and as powerfull as possible, allowing the developement process be way faster and scalable for Web3 needs
The Orivon goal is all about giving an organized system to build these Apps and make them work well together
All Integrations an App can have within Orivon API/Lib/SDK
Dashboard: only 1 App can be chosen as dashboard, every new tab from the browser will open the dashboard, in the beneath, itâs just a site avaiable under http://127.0.0.1/dashboard. Dashboard Apps has access to App list, widgets, etc..
DNS Resolution: allows an App to implement their own way of DNS resolution (ENS, custom ICANN etcâŚ)
Data Gathering and site loading: the way of getting acutal data after receiving DNS Records (IPFS, IP Address, Arweave, Ethereum Blockchain etcâŚ)
Account extensor: allows you to add to accounts to the Wallet, for example trough mnemonic, or hardware wallet, or anything else by App logic
Wallet extensor: allows to implement a new Crypto with a possibly standardized TAG and set of functions, then, another App, can use them to generate sections of addresses for that Crypto, like Ethereum vanity addresses (or simple Monero addresses, if alredy didnât)
Network: Apps wich gives some network access to other apps, like to Bitcoin, or Monero, or Bisq pricenode, the node could be both remote or ran in the user pc
Integration Apps may be installed globally to make their functionalities avaiable on other browser profiles, or, as by default, in the profile
Each App is going to have different permissions to access data or to integract within the browser to perform their tasks, the user should be aware of what an App can do and what it canât and we should guarantee the best security out of this.
DNS Resolution
Apps can implement support for multiple first level domains, Orivon has a table avaiable in settings for each first level domain, and the selected default App assigned to resolve it, if an App fails to solve a domain, another try may be given to a second App if it declares support to the same domain
Apps should then provide all domain records to allow futher browser handling and resolution
Data Gathering and site loading
Apps can implement support for different ways to acutally load a website from the DNS Records
Some examples may be loading trough IPFS, IP but with proxy, Arweave, Ethereum chain, Install it from github and run to load locally (that last one is a crazy shot, but someone may acutally need something similar)
Priority of wich App should try to load first can be changed in settings, or temporaliry on-the-fly from the toolbar, if an App fails to load a site, the work will be handled to the next one lower in priority
These Apps has the task of enstablishing if during the navigation on the website DDOC is verified or not, and communicate it to the Browser
Wallet system
There are 3 layers of integration for Apps into the Wallet system
This allows from a single Account to have a wide possibility of features from a single key of access
Layer 1: Accounts
Wallet are organized in accounts, one of wich can be the default and will connect automatically to any Website visited (thatâs deactivable from settings)
Every account may represent a Mnemonic, a Hard wallet account, or anything else by the integration App logic (maybe an account DAO Based, a multisig or something else), at transaction these Apps may need to open a GUI to complete the operation. Every account type may expose various functions to make them integrable with as most crypto as possible (relative standards yet to define)
Layer 2: Crypto
An App can integrate a new Crypto into the wallet which manages everything about it, like network, exposing to Section Integration Apps functions so that they can generate addresses, sign and verify transactions and get any other useful data (for example monero, you need to get trough a Crypto integration with some level of key access to get certain data)
Each Crypto is identified trough a TAG (ex: MONERO_V1), so that websites can use a single standardized string to know if a specific crypto is integrated in the Browser, interact with that and help the community to define standards on it (like exposed function names and behaivors for Section Integrations to use)
Layer 3: Address book
Then Apps may want to acutally add sections of addresses to the Wallet for that Crypto (for bitcoin with bcq1 or 1 or 3 addresses, ethereum with both normal or vanity addresses or Gnosis safe etcâŚ), they can do it interacting with the Crypto integration exposed functions. These too, can open a GUI to complete the operation
Connections system
With user permission, an App can expose connection trough a Proxy in the user device
You can set a Browser Proxy, or a different Proxy for each App, thus creating a proxychains effect, to prevent loops, browser look for them everytime a proxy setting is changed for App, preventing the user from creating loops, or blocking their traffic.
For each Browser Proxy setting (global or for specific App), every App exposing a proxy is shown, so thatâs more user friendly than a bunch of ip and ports
Futhermore, you can create Network Apps, their job is to give access to other Apps on a specific network trough possibly standardized functions for each network, and then Integrating settings of it in the Browser, avaiable on âNODESâ section.
From NODES you should be able to see how connection happens, use your own node, or possibly create one right away (or search in Appstore apps that can run a node on that Newwork)
Web3sites installable as Apps
Acutally any reputable Web3site should be installable and runnable locally, so the difference between App and Web3sites starts to disappear, installation simply happens by storing every static file of the site into a folder, wich will be used from browser when opened, and eventually, checking for updates
Why reputable Web3sites should be always installable and runnable locally?
Because otherwise means that potentially you are putting trust into different third parties at each page reload, the root of the Web3site should be predictable, and possibly itâs Ownership binded to a domain, so that a Trustlessity score can be given and shared
Web3 Verification: Trustlessity and Security Score
Web3sites/Integrations/Apps, Networks, and Operations has a Trustlessity score, shown near to the page url with a pie graph, filling more for each level and getting from red to green, Web3 icon when its full, yellow Web2 icon when level 1
Exhists also a Privacy Bonus to the Trustlessity pie, colored with purple
When an assessment hasnât been done yet, it will be gray with a small â?â
Clicking into it will give you more details about what this indicator is, how it works, and results of the audit, all shown to the user in the most trasparent way possible
Security Score is avaiable only for Operations, and shows, in the sum, how risky the operation is from a technical level
Levels for Websites
Level 1: Itâs a standard website, without DDOC (Domain Data Ownership Certification) (Automatically detected)
Level 2: The site supports DDOC (Automatically detected)
Level 3: The site root is open source and wonât execute any external script without the user willwant and knowledge of itâs risk/trustlessness
Level 4: The site is enough trustless into all of its operations (Level 4 operations) and external connections (Level 2 connections) (even if passive, for example, getting an IBAN from a bank isnât accepted for this level, itâs a passive Operation Level 1)
Level 4 + Privacy: Every activity on the Web3site is reasonably enough privacy preserving and keeping user aware the conseguence of possibly risky actions
Levels for Operations (sending money, smart contract, transaction, signing)
Level 1: The operation or some parts of itâs source code arenât avaiable / Itâs not possible to know whatâs really going on
Level 2: The operation source code is avaiable and does what promised / Can be verified that does itâs logic does what promised
Level 3: All the Network contexts the operations relies on, are considerated trustless enough (Like Bitcoin, Ethereum etcâŚ)
Level 4: The operation does not allows centralized or untrusted decentralized parties to act against the user interests, compared to the operation promise. (decentralized actors like DAOâs are still allowed, but should be considered safe and decentralized enough)
Level 5: The operation is immutable and does what promised in a completly trustless manner, a third party can have special powers on it for security reasons, but these canât never go against user interests by design (Ex. an Ethereum L2 may have a security stop in case of vulnerability rolling back at few hours before, but user should be always able to exit within a reasonable amount of time)
Level 4/5 + Privacy: The operation is reasonably untrackable and indecipherable by anyone else other than the user
Levels for Connection to network (trustlessity of your connection)
Level 1: The connection relies on centralized parties, received data verification is not possible
Level 2: The connection allows to verify received data and wonât put user at particular risk
Level 3: The connection is completly decentralized
Level 3 + Privacy: The connections gives reasonable anonimity
Web3 Search
For the supported seach engines (centralized or not), you can activate with a single button from Extensions Toolbar (or widgets), the search in Web3 mode, setting the engine in a way thatâs going to provide the best Web3 results, finding direcly results like DApps or other decentralized things
Anyway decentalized search engines will be preferred an possibly pre-integrated
Native Data Gathering DDOC Support
Orivon implements natively a way for sites to have DDOC, it works by trying to load example.com/path/index.html.hashes, if the site supports DDOC the hash-tree fill will be received, always containing the Core hash-tree and the Page hash-tree.
Core hash-tree is always the same, itâs contains the hashes, of every Page hash-tree.
What is a Page hash-tree? Every html openable on the website is considered a page, example.com/path1/index.html or example.com/path1/test.html or example.com/index.html, each of these pages has their own Page hash-tree, which contains the path of every file this page may load followed by their hash.
The Core hash-tree will be hashed, and verified if its equal to the DNS record âDDOC {hash}â, then, if the Browser ever happens to receive a file also avaiable in the Page hash-tree, it will verify the hash of itâs content, if it mismatch, DDOC immediatly fails, potentially alerting the user of possible site compromission
Script for site owners
Who owns a Static Export (or builded) website will be able to add support of DDOC by simply running a script, wich will add needed files in the site source, and will output the value to add under the text DNS Record (example: âDDOC {hash}â)
The script is going to run headless chromium to identify all files each html will load, to generate the appropriate Page hash-tree.
Currently we havenât plans for dynamic sites like PHP because usually they do not guarantee the same level of security DDOC aims, if you think otherwise you can argument it here, we are all happy to get advices
SoâŚ
Now a sidenote for Appstore and Trustlessity score, during the first days of the Browser we may opt for a temporary centralized solution, but eventually they will be both made Trustless and Web3 compliant, but who knows⌠maybe some other sub-communityes around Orivon will work on that decentralized solutions faster that us, in that case we may decide to pre-integrate them as default, time will tell
Futhermore, we should take in consideration future Mobile cross-compatibility for most App Integration types, and expecially for the deeper JS and Wasm APIâs.
Sites and Apps Developers should only worry to make a better frontend for each platform, anything else should be able to work everywhere out-of-the-box
But as now, leave here feedbacks and discussions, we apprecciate your effort to get involved into this, itâs a community project, everyone can be a foundamental building piece and in future should be compensated with the results from all of this