Learning C++

Screw Javascript. I already have a basic grounding in C/C++ through Arduino, so I've racked up a queue of youtube tutorials on C++ programming, starting with FreeCodeCamp's "Learn C++ in 31 Hours." You read that right. I'm a handful of chapters from Pointers, that scares me a bit, they break my brain a lot. On the plus side, this guy is a pretty good tutor, so far, and has clarified a few things for me, and cleared up some better practices. I'm learning a bit about my Mac, too. (M1 Macs, being ARM powered, don't do long double float point numbers. Too bad if you need to count stars in the milky way and store terrabytes of data on each... meh.)

screenshot of wikipedia article on peer-to-peer

I have quite a bit of respect for the Arduino platform basing their language on a subset of C++, it's enough C for beginners, and provides a really good, baremetal grounding in the language, but it also has a good subset of the pluspluses and OOPs, too, for people who want to reshape the universe in code. Well, the internet of things, anyway. I'm looking forward to understanding beyond the micro, and getting my arms up to my elbows filthy in systems code:- network interfaces, DNS tricks, etc. So to do that, I have to get dirty with real C++.

"But why?" asks my friend, Jeff. The "Everest excuse," because it's there, begging to be learned. Also, I have ideas. More than that, I have opinions, like a cat at dinnertime. One of those opinions is as follows...

  1. End-to-end encrypted, peer-to-peer networks are the safest form of internet we can have, especially for web publishing. The trouble is, while even "Web1" has a simple, navigable user interface that most humans can understand, at least with a little training, peer-to-peer is not. It lacks standardisations, it's a race of platform against platform. The bittorrent model is a good approach, but is feared by many as "illegal filesharing." There is no such thing as illegal filesharing. Copyright is a civil matter, not a criminal one. In principle at least.
  2. There is no standardised, across-all-subnets, peer-to-peer, domain and path protocol. Not the http stuff, the behind the scenes protocols that manage the dot.coms in a human readable way like, mydomain.com/path/to/webapp bit. Peer-to-peer is a mess of visible hashes. Look at an IPFS url. Go try to find one! Unless you work in hashes for your living, there is no way those great, long strings of crypto are as catchy as shinyhappyrainbows.com - this latter hides an ip number. Four, in fact, a quick dig (literally "dig shinyhappyrainbows.com" on my CLI) reveals...
    • shinyhappyrainbows.com. 1799 IN A 216.239.38.21
    • shinyhappyrainbows.com. 1799 IN A 216.239.34.21
    • shinyhappyrainbows.com. 1799 IN A 216.239.36.21
    • shinyhappyrainbows.com. 1799 IN A 216.239.32.21
    ...to do this site on i2p or ipfs would look somthing like i2p://kjhgdfiuyqt%$bdk#$ajgdf... etc. Seriously!
  3. Blockchain systems are getting on top of this obfuscated mess, but carry another problem. The maximum length of any blockchain is potentially infinite. Not for, say the life of a car, half a dozen owners, but definitely shares, individual copies of books or music, or ANY persistent transaction across generations. And blockchains ARE growing, like topsy! Again, many standards, therefore, there are no standards.
  4. The first/oldest database on the client/server world wide web is the domain name system. It dates back to before the web, when the internet was all commandline, ftp, gopherspace, usenet and there was no http and WWW. DNS IS the internet. Every web page, every email, every file in a filestore, is a node, an address, a point in cyberspace. These nodes have "local paths" to them, the /path/to/node part, that are pointers to where the file is stored on the server. Then there's the domain, the HERE_I_AM_[DOT]_COM, a neon sign that tells the world where that server is. This is what makes up this first and oldest database, all the servers, everywhere, findable all at once. It's "google maps" for our web browsers. ANY request, a video call, an email exchange, a music download or stream - all of these start with [protocol]:// appended with a [domain.tld]/ optionaly appended with a [path/to/a/service]. I nearly don't need to remind us of this, other than to explain the next paragraph, we all know this addressing method, we use it every day! I am using it to write this post!

    Peer to peer stuff has none of this. Peer-to-peer is an unreadable blob of randomly generated text-and-punctuation-characters. Why? Because peer-to-peer hasn't started AT THE BEGINNING! Nearly every single attempt at building a peer-to-peer secure, person-to-person, device-to-device network begins with the data and the connection, rather than with the database. If we start building a house from the roof, down, what will we get? A messy pile of building materials, probably much of that broken and unreusable.

    That's the state of the current peer-to-peer model.

    It's OK to use the current protocols. They're just connection tools, like the buttons or dial on an old boomer's wall phone. But where peer-to-peer models are currently broken, in part or whole, is they're reinventing the "house," starting with the "roof." We need to start with the "plan," aka, the domain system, the name.type. Trouble is, it also has to be secure, so simply becoming me@my.phone is not going to work. It cannot be human readable, by design, if we use the current, client/server models.

    How did we stay secure, but still communicate with friends before the internet and before the telephone? We had a known address and a locked door. Addresses were heirachical. You could have address duplication in different towns and regions, but not in the same town. In greater Melbourne, there are many Swanston Streets, but there is only one in the City of Melbourne, there's another in City of Darebin, a northern suburb of Melbourne, there are a few others. I grew up in York St, Campbell St and Ramsay St in my home town and have lived barely a stone's throw from streets of the same name in other cities. We all live cheek-by-jowel in our cities and towns, postcode by postcode, all with address parts in common, but never the same, literal address is held by 2 people, because of the heirarchy of nation, province, region, town, street.

    So, how do we create an address system, that is unique per user, human readable and secure? I'ma posit a dictionary. A literal dictionary. The Oxford holds 600,000 words, but lets use wiktionary, as it's creative commons, and credit them as our address data source for a peer-to-peer domain name system. There are more than 700,000 english word entries on wiktionary, with more than 1.4 million definitions. Lets keep address to, say, common, 6-letter words, maybe we have 500,000 words to chose from. I pluck that number, but it will serve to illustrate.

    Now, lets say, we each get a randomly chosen ID when we first create our profile on a hypothetical peer-to-peer network app. It's like the secret password generators some internet service providers use to create your backend login between your home network switch and the broadband modem plugged into the wall. So, imagine I've created an app that allows individuals to interact socially, one-to-one, one to many, many to one and many-to-many and I launch my phone app for the first time. It asks me if I have a domain, I don't, I select "Random domain" and it generates, "pluck.city.horse.fiddle" randomly, from the "500,000" english words of 6 letters or fewer, and more than 3 letters, on wiktionary.

    I run an instance of the hypothetical app on my computer and, to test this out, I create a different profile, getting, "nation.words.common.still" and I connect this app to pttps://pluck.city.horse.fiddle/ and the index page asks, "Do I know you?" From here, I could combine my phone and computer profiles, or I could run separate profiles on the two devices. I could have maybe connected my phone to my laptop at pttps://nation.words.common.still/ everybody gets a random domain, that's checked for not already being in existence, and for which there are at least 500,000 to the 4th power possibilities before we run out of unique, memorable domains. Allow people to add there own name to the front, and it becomes possible to have a single, family domain with mum.pluck.city.horse.fiddle, dad.pluck.city.horse.fiddle, johnny.pluck.city.horse.fiddle and jenny.pluck.city.horse.fiddle, etc. You could even use a registered domain as an alias overlay, like a 3 level system, for business. A client server domain, overlaid on a peer-to-peer domain, overlaid on the hashtable.

    From that point, I begin sharing the app to family and friends.

    What's so cool about this? Connection is a protocol and naming convention similar to what we already use, except, we have an ad-hoc domain name system overlaid onto the distributed hashtables of current peer-to-peer networks. Connections are via a visible secure protocol we know and trust while, replacing IP numbers below the hood are those awful hashtables common (and visible!) in state-of-the-art peer-to-peer addresses. We have an amusing, checkable, changeable, human readable, 3 to 6 word domain name, passed via secure socket layer, to the hashtable behind the domain. It's web 2 usuability with web 3 security and decentralisation. No blockchains, no complex hash address, still end to end encrypted. (https... although it could be, say, pttps:// as a nod to history and the future.)

    This model is the secret to getting peer-to-peer recognised as a proper standard protocol _AND_ accepted by ordinary people with no time for the "stink of nerd" in their lives. I stink of nerd, I'm not offended by the term, most people don't want to deal with technology, they just want to do business or chat with mum. That's what made the web take off - it was possible to use email easily, do business, and share web pages with mum. That's what peer-to-peer needs to do. The security is already invented, now lets hide it behind the interfaces we already know and love, make those a standardised, open protocol and wipe X off the face of the planet.

    And that, boys and girls, is why I'm learning C++! While appdevs are playing with their toy, Javascript, I'm looking to create an infrastructure, not an app!

Comments

Popular posts from this blog

Because I'm That Kind of Crazy

Meanwhile, Developing a MIDI, Tap-Tempo, Master-Clock Pedal...

Crosspost of First Post From New Riding Blog, “Diary of an eConvert."