old Home

Table of Contents

Update 6/11/21

I've realized I can move way faster in C# than I can in Go and I've had some better thoughts about how to design things, so I've clean-rebooted the C# code in the BrightChain repo. I'll probably borrow back a lot of code, but I'm ditching the whole tapestry metaphor in favor of more traditional business terms in the process. IPFS is no longer in the picture, at least not right now. Basically going back to my goals pre-discovering/being told about IPFS.

Update 5/8/21

BrightChain is about to undergo yet another extreme code change. Most of this wiki is still correct as it is generally big picture anyway, but just making readers aware that the actual brightChainAPI repo which was in its infancy is right now pretty much obsolete.

I think it'll be best if you start over at IPFS and then come here once you understand that.

Once you've done that, continue here. I'm just barely starting to understand IPFS, and some of these points I'm about to list may not be differences at all, and that would be GREAT. Notably, BrightChain is much more than just the blockstore- that's only the beginning.

Basically the prime differences and points of concern I see between IPFS and the blockstore of BrightChain:

• Blocks are whitened using the Owner-Free-Filesystem process which essentially eliminates copyright violation concerns for node-runners and shard-holders.
• Blocks are identified by the hash of its data, stopping before the counter fields and other options like keep until at least.
• Blocks are available in a small handful of fixed sizes to accommodate everything from small messages to terabyte files. All blocks in a chain must be the same size.
• When blocks are ingested, the user requesting the data storage requests a specific durability (higher replication vs allowing it to be local/ephemeral, or just standard procedures) as well as a "keep until at least" time, and a minimum access tier (glacier, cold, hot, etc). Eg if you request glacier but one or more of your blocks become hot because of someone elses block that matches and gets used in another file, that's fine because that's higher than you needed.
• • as blocks are Read, the requests increment last access counters and whatnot so the network can keep track of what blocks are hot or cold
• • as new files are ingested and duplicate block contents are encountered, they update the minimums (listed above) of the blocks
• All of this lets us essentially expire out some blocks that never get used, or only need to be stored for a period of time. Prevents storage creep forever.
• People who stored highly accessed content get perks from it, as do exit nodes and storage providers.
• The "money" end of it is not really money, but energy trading. You pay up front with your reputation and are rewarded in reputation.
• Content is accessed by requesting the top meta block of a file if that was stored (might not be for security) or otherwise requesting the "recipe" blocks of the file. A+B+C+Z, etc.

But BrightChain goes further, all the users are uniquely identified, and other crypto contracts and things will allow universal governmental voting and more.

Feel free to continue now. End of 5/8 update.

Back to Business

Introduction

Architecture

• Part 1: The Soup Market

• Part 2: Authentication

• Part 3: Identity and Central Authority - The Quorum

• Part 4: Reputation and Valuation

• Part 5: Digital Contracts and Secure Virtual Machine

Collaboration

• Off the Chain: #BrightChain Discord

• Collaborators

• Developing

Miscellaneous

• There are some as yet uncategorized thoughts that haven't made it into the wiki properly yet, here

** NOTE: At this time, there is a fair bit of write up on Discord that needs to be documented- as well as years worth up in my head. Ask me questions. I have answers.