69
« Last post by Rob Andrews on February 20, 2024, 09:06:55 PM »
Good evening and God bless everyone.
Before going into the new site, let me review some of our older web solutions:
First we had the BBP Foundation web site, which was simply a Microsoft site that used a conventional centralized database and allowed users to watch God videos, do fractional sanctuary staking, post twitter like alerts and had some gospel features.
Then we had BMS 1.0, where we had node-to-node (server) communication with an independent sidechain but it was limited in that it was not fully synchronized with the core wallet and it didn't have a very good UI layer.
Then we had Unchained.biblepay.org v7.1, which was an MVC solution, and finally did integrate with a cockroachdb cluster, had a non synchronized sidechain, could send money independent of bbp core wallet, had an API, and offered videos stored on BBP-wrapped-storj, and even hosted the BBP softphone. Although "warm", I was still looking for BBP to have a true synchronized and immutable sidechain offering, hence the reason for the rewrite. I also discovered that the in-wallet version of Unchained received very little interest since we could not make phone calls without launching the core wallet (it would be much more useful to make a call from a web page).
Now we have Unchained-RedSeaParting v1.37 that is being released. It is our MVP (minimal viable product release) of unchained. Meaning that this time, features do not exist in it that are not fully finished; they are held back.
This version attempts to "fix" all of the shortcomings in prior versions technologically speaking as each foundation has a pro and con. I have a plan to bridge permissions, business objects, the sidechain and the UI in a way that binds those fields to new pages in such a way as to make BBP a unique solution for certain apps. So when you are reviewing the UI you may think that it oddly feels like Windows, but that is by design. To give an example of what the vision is in the future, imagine this:
Rob owns XYZ corp, and grants (on chain) permissions to RWAD for two business object tables : property and lease to his BBP coworkers Alice and Bob. Bob grants R to John.
Then Bob creates a new page for viewing Lease and Adding Lease with 10 new fields. Each of these coworkers will be able to RWAD or R these pages respectively, all on chain. Hence the reason for the look and feel of "an app" and windows.
First, if you are coming from Unchained and you have an NFT or a balance, you can log in to this new version by pasting your private key as your password, and using your email address as your username.
You can get your private key by finding your "Unchained" address in your core wallet, and typing "dumpprivkey your_unchained_address". Once you are logged in you may change your password and hit Save.
Alternatively if you dont care about your old account you can Register as a new User.
Some things I would like to discuss:
Highlights of the new system
Things we Achieved (completed)
Things that are ToDo, and an updated roadmap
The Vision
TODO:
- Create a Responsive view for mobile devices. Right now the pages work on mobile, but they require you to pinch and squeeze.
- Linked immutable sidechain needs finished
- Permissions and Grants
- App sections backed by secured role views
- Sending a Note with a TX in the core wallet, and having the receiver read the note that is generated by the sidechain Inside the core wallet (demo hybrid integrated functionality)
Completed Items:
Note: The phone system now works from mobile phones as of today!
[Add Completed Items Here]
Vision:
- Permisionless Zero Trust security architecture (this means even the devs cannot break the security of the sidechain. Granted permissions are virtually impossible to hack-except by breaking a full key, even by the creator).
- Blocks are immutable and linked to the sidechain blocks in a forward only fashion. Nothing can be squeezed in between or rolled back, therefore they are immutable and secure.
- Temples provide the database security for our Cockroachdb cluster; with each temple required to run one cockroachdb node in the future (current state we run 3 from the first 3 temples to bootstrap the project until it is stable)
- Cockroach automatically "fills in the gaps" on unsynchronized content, which is very exciting. This means we scale. And we scale automatically.
For example, if 3/4 nodes are synced, and one new temple comes online, it will automatically sync or fill in the entire sidechain without any BBP code.
Cockroach also streams content in parallel, so when you request a report it is fulfilled by many nodes.
- The forward only sidechain block index has corresponding database Views that represent table objects for user consumption.
These always maintain their integrity since even if one was altered or corrupted, it would regenerate from the cluster, which is based on the forward only sidechain transactions that
drive the view. No user can alter the sidechain content, except by paying for transactions that go in it.
Transactions look like this:
BBP Core TX -> Contains Metadata
Sidechain TX -> Contains 1:many transactions that occur within one BBP block.
Each sidechain tx can alter a Business object, or can point to media (such as a video or a file).
Thousands of sidechain tx's can fit in one metadata tx that is secured by one BBP block.
The sidechain tx's are instantsend locked.
Sidechain transactions are almost instant because they run at the speed of our cluster.
Storage on the sidechain is cheap, and extremely cheap to use our sidechain to store videos or files, as we store the actual video or file on storj, and our sidechain stores the pointer to that data.
- Binding a new page to BBP objects will be simple once the foundation is released
- We have a new secure API. You can access certain API endpoints and functions with the BBP keypair.
Other endpoints require a temple (such as interacting in debug mode in prod from a hosted satellite).
- Field captions in our dictionary and language literals
- A temple is required to Host an unchained web satellite instance
By requiring a temple signing key for every cockroachdb write, we can securely maintain the integrity of every zero trust object in the view.
For example, if I own NFT 123, and I sell that NFT to user B, that sidechain transaction will only "transfer" via a hosted tx that executes on a web node owned by a Temple and that
temple signs the tx. This way, even our devs who debug the code cannot facilitate transactions in prod unless they debug from a temple, however we will have a Full testnet so that debugging is not a problem.
- Sanctuary voting for upcoming features
Let me know if anyone has any trouble signing in or testing.
Current state, unchained is meant to run on a desktop until we have bandwidth to tackle the Responsive Mobile endeavor.
Recent Posts