> I think it started to die when Google decided the XMPP spec was not good enough for them and deviated from it
It was my impression that Google dropped XMPP support not because of the spec being "not good", but because they saw now advantage allowing the federation, since nearly nobody else federated with them, while it comes with a cost.
The XMPP specification is open and in large parts malleable, nothing would have stopped Google from participating in improving it.
XMPP is still used in many places, including in online gaming https://xmpp.org/uses/gaming.html. Unfortunately without the federation support (which can be explained in those specific cases).
federation with xmpp doesn't need to be configured. it is automatic. all you need to do is to send a message to someone on a different server. i am not on google, so i used this all the time to talk to people on google. until they stopped.
to get advanced features, google would have had to create a client that uses those features. much like they created the chrome browser.
i guess there just wasn't enough value in doing so. and there were to few people like me who communicated from the outside.
Thanks for this, StackExchange was actually what I was thinking of when I wrote StackOverflow. Luckily, he also posts there a lot as well. I think my favorite answer is as below, as it's the first time I could recall a simplified answer of how TLS works, while retaining technical detail. A gift for sure...
First, let me say thank you for your efforts towards making DNS more accessible for implementors. Could you elaborate on "CNAME chasing to other zones: let’s not" and "Adding glue from other zones: let’s not"?
A common mistake made by "self-appointed" bitcoin experts and IMHO a good indicator for more red flags.
> On one side are those who believe that Bitcoin is … money, currency, …. On the other side are those who believe that it is a commodity, ….
That is the other red flag: Trying to construct two different exclusive camps. This goes along with not mentioning the Lightning Network (LN). Some people still don't see that LN could enable bitcoin to be both: A currency and a commodity.
LN has been vaporware for a long time, and it's always 18 months before it's ready. Recently the developers openly admitted they don't know how to scale it beyond 10000+ channels, because they don't know how to solve distributed routing.
That is a very pessimistic view on the current state of LN. There are three independent open-source LN implementations [1, 2, 3] out there that are being worked on and already implement basic functionality. All three contribute to an document, called Basics Of The Lightning Network (BOLT) [4], which forms an open standard for LN.
I wouldn't call it vaporware. Yes, there are unsurprisingly open questions. But nothing which can't be solved.
In the broad terms, how do you even imagine LN to work? Let's say I want to buy a $3 coffee at some random Starbucks I'm walking by. Do we have to first open and fund the channel? How much will it all cost just for that one off purchase?
Give particular figures please, no vague nonsense I hear all the time.
As for these implementations, I will believe it when I see it. You didn't even try to address the particular issue I mentioned.
You could be transacting your coffee with any crypto that Starbucks supports, and which is compatible with the lightning network. Litecoin will work for this example.
So Starbucks ask you to pay via Litecoin, which is fine by you even though you don't have a Litecoin balance. Atomic swaps over lightning network funded by some bitcoin you own, converted to Litecoin, is how you'll pay for your coffee.
Beyond what olegkikin mentions, the Lightning Network requires you to put stake (the total amount of bitcoin that can be used within those off-chain transactions). The illiquidity opportunity costs of that stake is greater than any value that the LN provides. There's a reason why we don't use pawn shops to buy groceries every week. Further, there isn't really a use case where you want to put some money at stake to do some transactions really quickly. Also, as Nakamoto† mentioned before, you can determine if a transaction is valid with very high probabilistic guarantee within a few seconds (with less risk than credit cards) without any change to the current network.
If for some reason you don't believe that, then there will always exist credit card companies that could provide instant transactions with guarantee as a middle man. Alternatively, there exists solutions like BitNotes.
"Open standard" doesn't really mean anything. It's standardized, in that there is a standard (actually, multiple compatible standards) that you can code to and end up with interoperable OCB. The complaint upthread is that OCB is patented, which it is. But for many years now, OCB has been free for open source software.
The license terms are vague. Is it connected to OpenSSL or not? Do you have to ask the author permission or not? And it is limited to open source software.
Nobody wants to involve expensive lawyers, so for many folks that rules out OCB.
Mosh is a great idea, but by connecting it to OCB, the authors completely stalled more widespread adoption. That, and like you said, the complete lack of protocol spec.
2. The consequences of quantitative easing will emerge and affect us all
3. Another cryptocurrency and bitcoin will form the backbone of a usable payment network with near-instant transactions for a low-fee