Accessing a “home computer” behind a NAT you don’t control or has a dynamic IP, eg. computers/devices that only have mobile connection and many (most?) broadband home connections.
I sometimes need to connect to a CI runner to debug some CI build script. I made a (quick hack of a) tool [0] for doing that by creating an Onion service on the runner listening to SSHD, and printing a one-liner I can paste on my dev machine to connect to it via Tor. This sounds like basically the same idea, but using a DHT and hole punching instead of onion routing.
It doesn't bring additional strength to the table, rather it's a country in need of protection. This means now every other NATO country has a higher chance of being forced in a defensive war if something happens to Finland. On the other hand Finland won't be able to contribute much to protect other NATO countries. Hence, NATO countries are a bit less safe now.
> It doesn't bring additional strength to the table
Strong disagree. With Finland, NATO's control of the Baltic sea is insurmountable. Together with Turkey's control on the Black Sea, this completely cripples any Russian maritime capabilities.
> rather it's a country in need of protection
Also unlikely. The geography of the Finish border is such that an invasion via land is incredibly difficult. Dense forest and mountainous terrain create many easily defended bottlenecks, and the Finns with their outsized artillery are in a perfect position to defend those.
Even without NATO protection, the Finish gave the Russians a very bloody nose the last time they tried to invade. Since then, the Finish military has been re-structured with the single purpose to defend against another Russian invasion, whereas the Russian military is constrained by many other factors. Any Russian advance against the EU now has to come via the Ukrainian and Polish plains.
> "having the instances always process [ops] in the same order" is basically not possible in any real-world network
By having 1) causal order (eg. using what the article refers to as Lamport Causal Clock) and 2) a deterministic sorting function to sort ops that happened concurrently (from the perspective of causal order), we can derive total order.
It’s absolutely possible and used.
And with those two properties, almost any data structure can be turned into a (op-based) CRDT.
That is to say, thoughtlede has it correct in their comments above.
We don’t assume “reliable delivery” in AP or eventually consistent systems. We assume “once all messages have been delivered…”
So if you have all messages and the two properties above, a total order can be derived.
You’re correct to say that causal order != total order as such but with the use of correct primitives, like Lamport Causal Clocks, we can get a nice and clean linear order of events :)
"correct primitives" do not by themselves provide a linear order of events
a
/ \
b c
\ /
d
b and c are concurrent updates, how do you resolve d?
it's a trick question, you can't resolve d without information loss, unless you bring in additional knowledge from the application
you can resolve d with information loss by defining some heuristic for ordering concurrent updates, a.k.a. last-writer-wins, basically picking one of those updates deterministically
that gets you a total order, but it's cheating: whichever concurrent updates you don't choose are lost, and that violates consistency for any replica(s) that are based on that state
> "correct primitives" do not by themselves provide a linear order of events
Review the description of Lamport Causal Clock in the article. Note that it carries “additional info” (additional to the example diagram). This “additional info” is what establishes the structure needed for total order.
> whichever concurrent updates you don't choose are lost, and that violates consistency
They’re not lost! The concurrent updates not chosen are still part of the “list of operations”, but the update to the data/value itself may not be observable if the subsequent update (the update that was sorted to be first) updates the same data/value (eg. both operations update the same key in a key-value structure). If the two operations update different data/value, then both updated values are observable. This isn’t cheating, rather it works exactly as expected: it is eventually consistent.
we are only talking about updates to a specific value here, obviously updates to independent values are trivial to resolve
it's possible to construct a CRDT such that concurrent updates are merged without data loss to a single "list of operations" maintained in the object, but that's not true in general
resolving conflicts with the lww strategy, or variants of that strategy that order concurrent events by e.g. node ID, are indeed eventually consistent at the highest level, but they provide no meaningful consistency guarantees to users, because they allows "committed" writes to be lost
Can you elaborate what do you mean by this? I was arguing that it’s possible as the original argument was “this is not possible in a real system and is only theoretical”.
> provide no meaningful consistency guarantees to users, because they allows "committed" writes to be lost
If I set the (shared) value to green and you set it to blue, what is the expected observed value? What if you set it to green and I set it blue, what is the observed value? More importantly, what is the consistency that was lost?
so there are multiple threads of conversation here
first, there is no straightforward way to module "a value" as a CRDT, precisely for the reason you point out: how to resolve conflicts between concurrent updates is not well-defined
concretely, if you set v=green and I set v=blue, then the expected observed value is undefined, without additional information
there are various ways to model values as CRDTs, each has different properties, the simplest way to model a value as a CRDT is with the LWW conflict resolution strategy, but this approach loses information
example: say your v=green is the last writer and wins, then I will observe (in my local replicas) that v=blue for a period of time until replication resolves the conflict, and sets (in my local replicas) v=green. when v changes from blue to green, the whole idea that v ever was blue is lost. after replication resolves the conflict, v was never blue. it was only ever green. but there was a period of time where i observed v as blue, right? that observation was invalid. that's a problem. consistency was lost there.
--
second
> almost any data structure can be turned into a (op-based) CRDT.
yes, in theory. but op-based CRDTs only work if message delivery between nodes is reliable. and no real-world network provides this property (while maintaining availability).
> there was a period of time where i observed v as blue, right? that observation was invalid.
Not invalid. The observation was correct at that time and place, meaning, in the partition that it was observed. This is the P in AP.
It seems to me that you’re talking about and arguing for synchronization, that is, consensus about the values (=state), which takes the system to CP as opposed to AP.
> there is no straightforward way to module "a value"
I would recommend to look into the “Register” (CR)data structure.
there is no single definition of a crdt "register"
i know this because i've implemented many versions of crdt "registers", with different properties, at scale
there are lww registers and multi-value registers, the former provides deterministic (but arbitrary) conflict resolution which loses information, the latter provides deterministic and non-arbitrary conflict resolution without losing information but with a more complex API
> The observation was correct at that time and place, meaning, in the partition that it was observed. This is the P in AP.
this is not what partition means
partition means that different subsets of nodes in a single system have different views on reality
if v=blue was true only during a partition, and is no longer represented in the history of v when the partition heals, then this value is not legal, violates serializability, is incorrect, etc.
> there are lww registers and multi-value registers
Use a single value register then in place where I said “register”.
> partition means that different subsets of nodes in a single system have different views on reality
Partition means that nodes of a (single) network are (temporarily) not connected.
In the example discussed here, blue and green were in different partitions thus had “different view” to the state. Once synchronized, their view on the state is consistent and both observe both values, blue being the latest state.
> is no longer represented in the history of v when the partition heals
Please review the above discussion again and the original article. You keep saying this but it’s shown in both that it’s is not true.
"last writer wins" does not preserve state from losing (earlier) writers/writes
after synchronization, all nodes share a consistent view of state (yes) but that state has no history, it only contains the net final value (blue) as the singular and true state
this is not complicated, i think you're out of your element
> The fact that I have not met a single knowledgable person who managed to convince me that NFTs are a good technology that solves problems that need solving in elegant ways doesn't speak about me, it speaks about the topic at hand.
It doesn’t say anything about the correct answer to the question and all about your analysis process. Keep looking, good luck!
At some point, it's possible to draw conclusions from the fact that a whole bunch of generally intelligent people can't make a good argument for something's worth.
For example:
> The fact that I have not met a single knowledgable person who managed to convince me that eating poop is a good idea that solves problems that need solving in elegant ways doesn't speak about me, it speaks about the topic at hand.
Do we conclude that eating poop is a great idea, and that more looking is what's needed? Or can we conclude that there's probably a reason folks struggle to justify the concept?
> It doesn’t say anything about the correct answer to the question
It doesn't necessarily say something about the correct answer to the question. That however doesn't automatically mean it never says something about the correct answer to the question.
I personally don’t want to use a domain name for everything. I want all my identities to be unique, I want an infinite number of them, that I can change between multiple ones per service and that they’re not connected to each other unless I specifically say so, and they should be fully free and permission less for me to create.
Public/private keys have or enable all those properties.
While there a many problems with how domains work today as a public goods system, domain names as identities is infinitely better than what we have now, but I think we can have it much better and domain names are one step in that self-sovereign ownership.
I think you missed the part when the original username was a subdomain of bluesky. There will be a great many anonymous registration services I'm sure. And things like afraid.org make that number of possible domains you can use anonymously a truly massive number.
The problem with pub/priv keys as user identities is discoverability and validation. How do I find your key? How do I prove this key is actually yours? Sure they are anonymous, but that isn't a desirable property if you are an established public figure.
Most of us are not established public figures and many of us, I’m sure, want to keep it that way.
With keys, validation can happen in several ways: attestation by reputable orgs, reputation systems, off-band, 2FA, “Hi, I’m John”, etc etc. Discovery is also highly context dependent in that it can and should happen “in the app/system” (=whatever the context of the use case is, eg. you know me by pubkey 123, the tax office knows me by pubkey xyz).
“anonymous registration services” from the perspective of self-sovereign identity is by definition not anonymous :)
To be clear, I understand the desire for truly anonymous services. But after two decades of experimenting and thinking of this problem. I don't think it is possible for an truly anonymous solution that is also ergonomic to use.
Things like briar exist, and for you use cases, existing tools might be enough. Briar is fantastic for communicating with people you know and willing to jump through some hoops be part of a community that is anonymous, secure, and provides lots of ways of making introductions and posts.
But there are reasons why Meta, Twitter, Linkedin and the like are well above any anonymous solution in terms of users.
- Identity (including pseudo identity of anonymous users) is established.
- Spam. There is ungodly amount of spammers out there, as email has shown. If you have played with nostr or scuttlebutt you would also see just how horrible the spam is.
- Account recovery, people are bad with passwords and storing secrets. Very bad. And even the most secure people can get exploited.
- Hosting your data is problematic. Who hosts data which may be illegal? When illegal data is flagged, how does it get purged? Merely being the transit for data is protected in the US, but physically hosting that data is not.
- The vast majority of people are unable to run a persistent service for their identity and content. Even if they are willing, they lack the means. You end up targeting a very small subset of people who are willing, able, and capable of running a service. And that service requires care and feeding. You might end up with millions of vulnerable instances.
- Scalability. No one has come remotely close to solving how one of these solutions would scale to billions of users. Or even tens of millions. DHTs become painfully slow and bloated. Even if a solution did start catching on, it would quickly then fail because the user experience would crater as it gains popularity.
I have become convinced that making an ergonomic briar is impossible without making some concessions.
Complaining that a new and unproven tool's chosen concessions are bad inhibits experimentation.
The problem with infinite, easy to create identities leads to a well researched attack, known as a Sybil[1] attack.
If there isn't some type of cost or friction to creating identities, you will have a lot of bad behavior, full stop. This has been shown time and time again, so it's basically a non-starter. I don't want to be part of any social network that has this feature (infinite identities), its going to eventually turn to shit or require intense moderation (or both!)
I think this is true if the system is global or there’s model where Sybil resistance is “here everyone, have an access to write to the database”. In a system like HN there’s value in Sybil resistance. On your Twitter feed, almost none.
So I disagree this is a non-starter, because we didn’t find a solution in the past, but rather an ideal place to start and a great space to discover new Sybil resistance mechanisms (which we have over the recent years).
Domain based identity also enables attestation which could be use to artificially add even more friction. Plus, since it's not constrained to a single platform, you could have 3rd parties that assess trust and reputation.
CRDTs is how sync issues become non-issues. The “correct sync” is deterministically determined by the CRDT conflict resolution algorithm. There can be multiple DBs/stores per app or per user or per whatever makes sense. One big global DB/store broken down to millions of DBs/stores.
Merge conflicts that must be resolved by the user (i.e. when there is no logical way to determine the priority of two offline changes) are still an application specific problem, even with CRDTs. You can build structures that allow storing conflict resolutions in CRDTs, but getting them right is still like half the problem to solve.
I have lack of imagination to think what kind of conflicts those would be, would you have examples?
In my experience there’s always a logical way to solve conflicts. And CRDTs can have any kind of conflict resolution algorithm, so it’s customizable per application. “Storing conflict resolutions”, eg. “a merge operation”, is not needed and unnecessarily complicates any CRDT.
Yes, sometimes it is hard to come up with the merge strategy that preserves user intent. I think the big one is rich text, where Peritext[0] looks like a good direction.
Then you get to deal with conflict resolution, which is a rare dragon that is kind of confusing and sometimes has to ask the user which state they'd like to keep.
Another possibility is to assume the user is the authority and is always right. For example, if I post a tweet to my feed, I’m (or should be) the authority and always right.
The previous comment didn’t ask for consensus for a social media or communication protocol specifically but rather was two steps ahead and was referring to the infrastructure that those protocols run on. Under the hood, there are various consensus mechanisms in current day social media or communication protocol infrastructure systems and those systems are needed to make sure (user) data is available. In order to run a data availability system, there’s a consensus required somewhere there. If you want to have the infrastructure provider run it “honestly”, in a protocol sense, then you need incentives for them to do so. If you need incentives, then you need kind of transactional system in a payment and accounting system sense. And that’s where you then need to care about “double spending”.
Gateway operators are paid to successfully process data (which they can do if they stay online, have a fast connection to the Internet, and so on - not a shitty Raspberry Pi)
Gateway operators are paid to store data
Gateway operators are paid to mix client-side encrypted messages and shred message metadata
Gateway operators are staking their nodes to ensure cryptographically correct operation
If you want to see more, spend some time reading how blockchain-based networks with incentives work.
That describes most centralized services on the web today. Nostr and other decentralized protocols aren’t aiming to recreate the Twitter and Amazon model.
These services exist outside of the protocol and depend on a few centralized and trusted authorities.
Another solution that is arguably more resistant to capture and censorship would be to use a blockchain to manage user name aliases - like Farcaster is doing with fnames.[1]
Think of cryptos more like “incentives to rational behavior” than “money” and it starts to make sense. You can incentivize, for example, data availability with cryptos and that opens the design space for distributed systems that don’t need to be controlled by one entity (like Twitter, for example).
There are two places where a blockchain would be very useful in this context: guaranteeing completeness (allowing you to confirm whether or not you have downloaded all the posts ever created by a user), and preventing timestamp forgery.
SSB has something like this but it requires a user to download another user’s entire post history before being able to see one post. Makes the experience very slow.
Crypto movement does not relate to bitcoin. Bitcoin was about preventing money printing and crypto is about every VC having his own private money system he sells token of
I didn't say decentralised timestamping is required for a social network or any blockchain needed
I read up on what Protocol Labs are doing. Seems pretty not-useful to me living in the real world. I'm pretty sure distributed vague-but-epic-crypto-bro-sounding super-important-"let's back up the worlds most important information on the blockchain and also it's a file system like dropbox but on the chain" resonates with some folks, but to me, it's just more of the same: rich folks saying that they better have control of the info, the coins, the way its distributed. It all comes down to _agency_. They actually want to be a centralized owner of information. Crypto is full of ridiculous offerings like Protocol Labs.
I think the web already solves this problem. That's the larger issue I have with web3, trying to solve a problem that doesn't exist.
I appreciate you reading to and responding to my words, and I'll try to find something useful in their offering in the real world. But, honestly, their layoff statement was all I needed to know, a CEO completely out of touch with main street and living in the crypto-futurist-whiz-bang-only-for-rich-folks future. Maybe one day folks will call things as they see it, for instance blockchain might have a future as a rebrand under "append-only ledgers" (technology from the 1970's), etc. But a specific example, just for the sake of discourse, would be appreciated here.
