0 sats \ 11 replies \ @huluvublue 4 Sep 2023 \ on: Removing the last few middleman tech
I'd like to see a Bitcoin native distributed storage and compute scaling layer. IPFS has a lot of recent advancements like IPNI, WNFS, IPVM, Bacalhau etc. We will get there eventually whether its with drivechain or ZK or some other innovative 2 way peg.
I think all of the above sounds really good.
One other issue that gets pulled in , how do we bootstrap? Essentially we are talking about DHT https://en.wikipedia.org/wiki/Distributed_hash_table (bit-torrent or similar) .
In my initial view/thoughts , the coop operating the CDN/DNS would also operate boostrap/discovery nodes.
One problem I want to solve for MorseNET is that one must presume all delegated operators (aka system/network admins) are untrustworthy (either they are, or they get targeted/compromised etc). I want the MorseNET to have a blockchain that records all privileged operations . Ideally this would tie in with a ticket system. So that if say someone is just randomly firing up a network sniffer on the router, without a specific need, it would be logged to the blockchain. The system would ship with a number of pre-canned alerts that everyone would be subscribed to.
I want this kind of system for anyone running critical infrastructure with delegated authority. Total enforced transparency. Yes, from time to time, often daily, personnel with privileged access need to perform operations that may impact privacy. Those actions should be recorded.
Because, while the system your designing ensures no one has tampered/blocked/altered the traffic (which is absolutely something that end users care about and should be able to know/prove/have attested to), it doesn't cover the threat model of delegated authority being able to read/copy/monitor traffic.
I looked into things like blockchain append only databases a few years back.
(This is something that I don't expect a deep answer on, and would fall into consulting/billable/equity/v4v time) .
We have orthogonal goals/objectives . Ultimately we want high trust and the absolute reduction of risk while not impacting usability (I am sorry if that puts words in your mouth, but it's what I'm gathering from these interactions) :)
reply
Yes. IPFS/associated projects does seem to be the space to watch.
However, without a cooperatively owned/operated set of compute/network/storage resources, it's suffering the same fate / risk profile.
I would like to see a community effort to constantly purchase inventory (for now on VPS/colo providers, later on our own hardware) that could use a NixOS build and would join a "swarm" as an IPFS node (and also using opennic or whatever blockchain DNS folks reach concession on) (I personally think that blockchain DNS is solving the "ownership" problem at the wrong layer .)
reply
Agreed. We need something people can easily add atop their current node setup with little additional cost or technical experience. Every umbrel node-in-a-box is sitting with 1.2 tb extra harrdrive space and a modern CPU. Opennic looks interesting, like a more honest attempt than unstoppable or handshake stuff?
Are you building in this area? this is my fav topic. We need a 2 way peg and incentives (luckily there this thing called bitcoin lol) and we can have an open source permissionless option to compete with google, amazon, openai and the rest of clownworld
reply
I am happy to be the project/product manager for something like this. That is what I have the bandwidth for. :) It's tangential to the overall goal of my business, and I have strong feelings/beliefs about it.
I have done limited research and have the kernel of an idea (a "trading bot" of sorts that has an account that is community funded and purchases inventory from lowendbox.com (i think they have an API site as well?) and spins up nodes. ) All using sats, all fully blockchain enabled/logged/visible. I presume we can have sats flow into an account, and then (automatically?) fill up fiat (after certain thresholds) with BTCRefill and use that to purchase inventory. Something like that. I would be happy to collaborate (I"m @ReachableCEO on Discord) and put some mindmaps / business process diagrams together. (I like https://www.insilmaril.de/vym/ and https://www.bonitasoft.com/ for that, but also interested in finally figuring out mermaid in markdown and realizing my dream of living in VsCode 99% ) .
We would need to figure out things like compliance (handling of money, filling up giftcards). It's a decent sized project. The technical side at first pass is working with IPFS experts and getting a (docker? nix?) stack going (integrating with Umbrel is nice, but I don't think folks would want to co-mingle things?) . Also this would best be run in data centers . If it's run in folks homes, it would need to be decent uptime and have ports open etc. Like a full BTC node :) (a well run one anyway).
Happy to flesh this out here as well. Don't want to pollute/spam. It's something I see as an interim goal between what we have today (emerging p2p/no middleman/border-less etc v4v) but with a vulnerable underbelly (centrally controlled DNS/CDN) and v4v riding on a cooperatively built/owned/operated network.
reply
Digging the direction you two are going with this. I've been giving it a lot of thought at the end-user level; ie- the content consumption layer. IMO there should defintely be a hash based routing system to checksumed content that results in an immutable/introspectable endpoint as with BTC addresses (and that perhaps are BTC addresses). Users as such can consume them as a QR making it 'fun' to collect and organize your content (websites, feeds, podcasts, movies, etc) & you could potentially add another incentive/reward system to convenience users by selling shorthand naming/namespaces to such a system ie- build our own alternate DNS complete with a domain registry. The benefit of such a system is that even if a user forgets to pay a bill and their namespace 'expires' their endpoint would continue functioning at its original hash address.
reply
What would that look like? I mean, in terms of UI/UX? Would this be a new kind of browser?
Is this something like NFT meets TOR? I am trying to wrap my head around what your describing.
Can you list out :
- how the current system works today (as you understand it)
- a workflow in that current system, as it currently works
- how your system would work
- the same workflow from 2 and how it would work in the system you are describing?
What are the key problems you are looking to solve?
In my mind, many of these high complexity systems “boil the ocean” and by taking “small” steps (like cooperative ownership of DNS/CDN) we can resolve (almost?) “all” concerns.
I think that sometimes ownership/stewardship/control and tech gets all intermixed. In my opinion existing tech (when it comes to things like DNS/CDN) is fine. The issue is the control/ownership/concentration. I don’t believe we “need” new tech stacks. We 100% need new/better/different governance and de-centralization of power/concentration. :)
New tech is of course wonderful and no reason to not let 1000 gardens bloom and see what develops etc etc.
I think, combining btc/v4v with “boring” tech gets us something “now” (ish) and serves as a nice interim solution to a nasty underbelly of vulnerability that everyone likes to pretend doesn’t exist :)
reply
Can you list out :
Well I can keep spitballing; if we get too structured here I'll have to bill you by the hour haha
Though am indeed building on my own right now just fleshing things out & prototyping; it's why this is great to have converstation with likeminds.
Definitely agree with you let's not reinvent the wheel. On that regard, I've given the backend some thought too and this ties in to what it would look like a little bit in terms of UX and how it works. IPFS is an example of something that is rather exotic and so I think we should be looking seriously at other existing file systems/networked systems already in production that guarantee file integrity specificaly the workhorses known as Git and ZFS which both happen also to be software engineering pinnacles IMHO. Primarily the reasons these 2 are so rock solid & widespread is that they are extremely focused on limited features but absolutely nailing those.
And like you said DNS/CDN pretty much fine and as such my thinking is you bootstrap on them; nothing is going to go anywhere if its not resolvable over http so what we could have is 'nodes' that expose a port and are as such reachable on http complete with the addressing system so that any given node can host all or some of the endpoints (content) over existing DNS + http ex: mydomain.com/somehash123435dfs/mynote.md
Hard pass on NFTs but methods of authentication/permission is important and this can effectively make it useful for communications too. Some method to accommodate licenseable content may also be worthy of implementation to help individual creators publish/monetize their endpoints if they so desire.
Like you pointed out we don't need a new tech stack, I would only suggest a clever content routing/addressing system combined with intuitive UI/UX & some aspect of branding - that aside we can tackle the more pressing and challenging political, monopolozation and man-in-the-middle vulnerabilities you highlight.
Your collaborative/crowdsourced/bot driven purchasing strategy seems very promising. I think also perhaps something early on to decide is if we would want to work towards IRL hardware ie- to get rackspace and/or have a data-center strategy.
reply
Ok…. however you didn’t answer my question :) Let me ask it more succinctly:
What workflow exists today that your system would replace/do differently?
I still have no idea what you want to build. A “clever content routing/addressing system combined with intuitive Ui/UX “ is a new tech stack in my opinion. Which, as I said, I’m not opposed to. I am just looking at this from a product management / requirements point of view and trying to understand the “why”. The “how” isn’t of particular interest to me (at this moment).
reply
HTTP and the domain name system (and by extension, email) today are the fiat of internet information exchange. The endpoints are not immutable, nor is the content at those endpoints verifiable (in most typical situations where the provider does not explicitly provide a checksum; SSL is some aspect of general end to end security but there's no checksum provided for the site's JavaScript bundle file for example). When endpoints go down, unless you have your own copy its gone (possibly recoverable on wayback machine, internet archive, or if you are lucky as a torrent/from a seeder if it was a large file for example)
We have verifiable/checksum based systems already like in Git or ZFS (and torrents)
So it's not about replacing the internet 'workflow' but rather integrating these verifiable file systems under the hood to make a better internet. Just like Bitcoin made a better money. It made the exchanging of information immutable; the endpoints are permanent.
At the risk of being too pie in the sky another 'workflow' example is email. There are of course a dozen contenders for making the next 'email' including Nostr but it's got its imperfections and I don't necessarily think they are optimizing for what I describe here. When you send an email, you don't want it eaten by man in the middle. This is a critical flaw right now today with email - some messages are actually blocked at the provider level like Gmail. And for those not blocked/rejected their solution to spam is to read your emails and filter on your behalf; today you send an email to someone for the first time and you must assume 10% chance you will go in the spam box and there's about a 1% chance every 60 days the recipient might look there and might actually see you in a sea of other msges.
Hash based endpoint system (instead of routing through IPs and domains) solves this and you can verifiably open your inbox - spam or no spam - and rest assured your mail provider or ISP hasn't filtered out messages; its like a Bitcoin address if someone sent you BTC you are not missing that transaction. To prevent/mitigate spam we can use sats to let users set an inbound fee not far unliike how Stackernews does; set your price for receiving a message from an untrusted provider and now even if you do get spam at least they paid you for the priveledge.
At the end of the day, you're going to need that 'killer app' to give these features first class treatment (not to mention native integration w/ Lightning for example) so yeah a browser / inbox viewer is something I have been tinkering on.
I understand you are looking at more logistical/infrastructure level vs yet more software engineering but having common goals helps bridge systems so perhaps we can find ways to overlap our endeavours & keep focused on doing what we respectively do best.