As a programmer (Or non-programmer with an idea), how would you go about decentralizing one computer from another, or to each other.

Say I want to write a chat application, how woudl computer A be able to know that computer B existed?

Or is the idea of complete decentralization not possible?

Most chat applications use a central server.  The server keeps a list of users/computers based on when someone authenticates.  The server routes messages from one user to the specified recipient(s) or broadcasts the message to everyone.  Most servers use push methodologies (such as web sockets) to deliver the message.  There are plenty of examples of how to write a chat application.  It's actually quite easy.

Yes, now, without having an intermediary server involved to connect the two computers.  How could they go about finding each other?

So you're saying you will have a bunch of computers on your network all running your application.  Computer 1 wants to send a message to computer x but computer 1 does not know the address of computer 1 and you don't want to have a central server coordinating the messaging.  Is that right?

When your app starts up:
Open a server socket on a specified port (pick a high port# to be used by all computers running your app) on the computer.
Then have your app obtain a list of ip addresses available on your network.
Walk through the address and attempt to connect to your port.
If you connect send a specified greeting and check that the proper response (including user id) is received.
If the response is correct add the info to a map.
Close the connection.

When you need to send a message:
See if your address map has an entry for the computer you wish to contact.
If you don't use logic from start up to find the desired destination.
Once you've found an address open a connection your port on that address.
Send the greeting and confirm the response.
If everything is good send message.
Close connection.
Update map as necessary (add new nodes, removed dead nodes).

No I will not write the code for you.

I appreciate the pseudo code as is, and no, I don't want you to write it for me.  (Learning swift to do this on a mac!)

Now, say the two computers are not on the same lan, say one is in NY and the other is in LA.  (Or any arbitrary place)

What scheme would you use to be able to make sure that these two can find each other?

What I can come up with is a server that hands out IP's - but I want it to be fully decentralized, where there is no intermediary server involved to connect these two computers together.

Ideas are welcome, workable and semi-non-workable.

so traffic would be a big concern to me.
you suck up bandwidth every call you make.

I am curious how blockchain does it.

I understand in theory every transaction gets called out to everyone holding a ledger that the bitcoin moved from my holding to your holding when we do a deal.

with no centrailzed server, how do they know who to talk to?
I mean they aren't calling someone specific, they are calling everyone, but there has to be some list to tell you who everyone is?

If traffic were not an issue, that list could be distributed.
like bit torrent, each person carries a piece of the message to be sent to one place.

Not a programmer... but RF is decentralized. Encryption is a no go on amateur radio frequencies but it *would* work.

Modes like JS8call are keyboard to keyboard. Problem is, it's open so everyone can read everyone else's traffic.

It sounds a lot like you're implementing the logic of a Layer 2(?) network (ARP sending a broadcast to everyone on the local network asking "Are you Bob?") The problem you identified with this is that all endpoints have to be in the same broadcast domain. ie: Everyone is in a big room, and you can yell directly to each person to ask them if they're Bob.

To go past this, you need to have a way for the searching node to know where to look for the recipient node. You pretty much need a broker of some sort to do this. The first quick & dirty answer that comes to mind is webserver each endpoint can get to. Each endpoint reaches out to the webserver, asks "Who do you know?" and pulls down a list of all known user addresses. The webserver adds the asking endpoint's address to its list.

You'd need a timeout of some sort too. Maybe the server removes addresses over 5 minutes old, and the endpoints have to ask for a new list every 5 minutes.

Then you need to think of how to keep this list of addresses secure... but that's getting a hair complex for where you are now.

The idea behind this is, How do you stop from being stopped?

A government does not like your content, they simply steal your domain from you (Look at backpage.com as an example).   If you are pointing your program at a domain to get a list of domains to get content from, they steal that domain and your program is dead in the water.

How can you communicate between Computer A and Computer B when neither one knows where to look for the initial packet of data?  What can be the arbiter of the initial packet, that simply can not be taken down?

Is there a 'first packet' problem that has already been solved that I just don't know about already?

(Edit:  Damn Dyslexia!)

Ok, maybe I made it unnecessarily complex.  How about, we use this model:

A single computer, it needs to get a piece of data (An IP address) to be able to connect to a remote machine.

How can this piece of data be assured of not being compromised?

If it is hard coded into the app, it can be pulled out easily and that IP then seized.

Once you leave your local network you really need a central server for your clients to authenticate to which would keep track of who is who and where to find them.  It will be just about impossible to "discover" your users on the fly in any sort of reasonable fashion. Once out on the web you will have to negotiate everything that makes the world wide web world wild.  At this point you need to get funding and hire a full blown professional development staff that specializes in building these types of applications (web infrastructure).  This has gone beyond the realm of a simple network chat programming exercise.

It was never a chat program, but the base idea is most easily expressed in that framework.

How can I bootstrap an initial handshake, without the endpoint being hardcoded into the program?  (Am I honing closer to the answer each time or getting further away?)

Simple answer is that you can't, at least on the scale you're talking about.  The only way to "find" an arbitrary device without some central repository of address information is an exhaustive search of the network.  Since the network in this case is "the internet," you're screwed.

Yup, kinda what I am thinking as well.  It needs an initial seed no matter how I cut it.

And with that I think this thread is done.  PM me if you want me.  I have real coding to do.

I imagine it would have to be a bit more low tech, in which there's a local directory or phone book distributed among clients rather than a shared address book.  Like a phone book or yellow pages, you'll require updates to be issued as addresses change.  A secondary form of distribution/ communication would be needed to acquire the phone book.

this is very straightforward to do, as long as both endpoints have visibility to the public internet and commonly used webscale features.

if that is the case, the means to do so are already in place and free to use for this purpose.

read:

https://en.wikipedia.org/wiki/Distributed_hash_table
https://en.wikipedia.org/wiki/Distributed_hash_table#Examples
https://en.wikipedia.org/wiki/Rendezvous_protocol
https://en.wikipedia.org/wiki/I2P
https://en.wikipedia.org/wiki/Freenet

etc

ETA
ps
even simpler, i just thought up a way to do StO (which you can evolve into CHAP) using DNS wildcards and (for example) apache virtual hosts.

example: via your SOA or your registrar, *.yourdomain.com points to a given IP, 1.2.3.4, which you control.

from anywhere on the internet, surf to www.yourdomain.com; you get a page of recipes.
from anywhere on the internet, surf to 0x123456.yourdomain.com; you get a page of recipes.
from anywhere on the internet, surf to whoareyou.yourdomain.com; you get a page of recipes
but
from anywhere on the internet, surf to seemingly_random_number.yourdomain.com; you get a page of interesting info, such as the current distributed hash table.

the seemingly random number is not actually random; it is a hash value made from several disparate pieces of info.

these info might be indexed from a one time pad, such as https://www.amazon.com/Million-Random-Digits-Normal-Deviates/dp/0833030477 appended to a varying value and then augmented with something of general knowledge but nevertheless unpredictable (the whole part of the DOW closing value on the prior day, for example).

so we know on a saturday (day6) in december (month12) we use a given page/row/column in the pad to find a random number, the seconds since the unix epoch is appended to that, and then the prior day DOW closing value is appended to that, and then the SHA256 hash of that is taken.

this hash is only useful for the next second* to retrieve the page of interesting info at ${hash}.yourdomain.com

(*) the server can build a 2 or 3 second moat in both directions (timewise) with absolutely no practical reduction in overall security since the keyspace is so large.

ar-jedi

Yes, that is getting closer to what I am looking for,.  I have some reading to do, thanks for the pointer!

or just build a tor hidden service to bootstrap the network.

IRC used to have some degree of decentralized communication. And that is OOOOLLLD technology on Internet terms. The problem with decentralized stuff is that all sorts of name and data collisions happen and the number of ways to manipulate or corrupt it goes way up.

https://en.wikipedia.org/wiki/Internet_Relay_Chat

https://en.wikipedia.org/wiki/Netsplit

Each client in the peers would have to host part of it, which opens up a can of worms for copyright and illegal type data.

One would have to either run it as part of an infection, or encrypt it so hard that the intermediate client host could never see the data that was temporarily (or permanently) stored. You would need to exchange public/private keys beforehand out of band or you would never know for sure if you are talking to the intended recipient or not. And that rules out just popping into a topic matter "room" and starting to talk to strangers.

True robust decentralized communication is a VERY hard problem to solve.

I am finding that out.  I am pretty sure though, there is a way to do it, I just haven't come up with it yet.