A decentralized, blockchain-based messaging network for safer communications

0x815@feddit.de to Technology@beehaw.org – 67 points –
A decentralized, blockchain-based messaging network for safer communications
techxplore.com

Researchers from several institutes worldwide recently developed Quarks, a new, decentralized messaging network based on blockchain technology. Their proposed system could overcome the limitations of most commonly used messaging platforms, allowing users to retain control over their personal data and other information they share online.

113

I'm a simple man, I see blockchain, I downvote.

I understand the impulse, but I think that’s a knee-jerk reaction. I am immediately suspicious of any technology that claims to use blockchains.

Possibly. But it's a well-deserved knee-jerk reaction. I just really hate reading anything the sick mind of a cryptobro has come up with.

I don't see how blockchain (in this case) adds any value over a federation like Matrix.

I doubt these bozos know of federation. Hell they forgot about the existence of p2p based comms like jami.

It adds value by helping convince clueless investors to give you money. I'm entirely serious. There's a significant number of investors that think blockchain technology is a good thing. Doesn't matter that it's a terrible solution to practically every problem. The goal isn't to be a good solution. The goal is to make money. They only need to convince a few clueless people to give them that.

This system is federated.

The blockchain means that you can access your encrypted messages even if your server goes down.

you and everyone can access those encrypted messages. You are the only one that can decrypt them, sure, but as others have already mentioned, the history of encrypted messages is almost as bad as the actual content.

Not everyone can access the encrypted messages. Only nodes with channel members can access them.

And everything is encrypted apart from the timestamp, so without decryption you can't really learn much.

2 more...

Publishing everything on a blockchain means that everybody who's running a node has access to a copy. If confidentiality of communications is an issue, this may as well be a data breach with a few more steps. Also, how does giving everybody running a part of or monitoring the blockchain equate with "control over personal data?"

Centralized control: Only one entity can see it. Blockchain: Lots of third parties run a node, so every node can see it.

Each channel has a separate ledger: That makes surveillance of a particular communications channel much easier. Thanks. Also, each user has to have a keypair; great for pseudnonymity, lousy for repudiability.

Messages cannot be altered but they can be audited to prove their metadata. Did they learn nothing from the Obama administration? At this point in the paper I can't shake the feeling that this is a deliberate effort to invert all of the properties of privacy.

Smart contract: Yay, more deliberately memory unsafe programming. I guess they never played with Core Wars as kids, either.

An attacker would be unable to breach the network: An attacker would just have to stand up a node. If channels are side ledgers on a blockchain, and the network assumes that nodes can come and go (which they all do, as far back as bitcoind), any node can join, say "Hey, I'd like to join this channel," and get at the very least a pointer to the side ledger for that channel.

Long-term storage of communications is dangerous, mm'kay?

Publishing everything on a blockchain means that everybody who’s running a node has access to a copy

I'm not sure that's the case, although the article is rather vague. It says:

[...] the user must register with a node of their choice using their public key. Once registered, users can create channels and invite others to join. Each channel has a separate ledger hosted by the nodes. [...] The data in the ledgers are encrypted, and the secret key is managed by the users of the channel.

IIUC, nodes will not have access to private keys, neither those from users nor those from channels. Users could use their keys to exchange the channel's private key without the node getting to know it. I don't quite understand how user's would exchange their public keys without the node being able to play MITM, though...

Edit: Removed an irrelevant sentence from the quote

I believe their point was that even encrypted messages convey data. So if you have a record of all the encrypted messages, you can still tell who was talking, when they were talking, and approximately how much they said, even if you can't read the messages.

If you wait until someone is gone and then loudly raid their house, you don't need to read their messages to guess the content of what they send to people as soon as they find out. Now you know who else you want to target, despite not being able to read a single message.

This type of metadata analysis is able to reveal a lot about what's being communicated. It's why private communication should be ephemeral, so that only what's directly intercepted can be scrutinized.

That was exactly why I said "Did they learn nothing from the Obama administration?"

From 2014: "We kill people based on metadata." (Michael Hayden, former DIRNSA, 2014.ev)

There is no "harmless" here.

But in this case, the metadata is not accessible to outsiders.

If you can see it, you can analyze it. Metadata is more than message headers; traffic analysis generates usable metadata, too.

Any form of internet communication is potentially susceptible to traffic analysis, so that flaw isn't specific to this particular design.

The goals here are to address some of the other weaknesses of communication protocols, ie lack of auditability and reliance on a central server. They do not claim it's completely impervious to attack.

Not sure how this would work, but potentially one advantage of blockchain over peer-to-peer is less metadata needed?

All the encrypted messaged just get dumped into the public blockchain, you might be able to glean who (or at least where) a message was sent from, but the reader could be anyone with a decryption key. A bigger channel, like a newsletter type thing would just involve more read keys being available. Kind of like old school cold war numbers stations or encoded messages in the classifieds. You might be able to figure out that KGB agent Pyotr placed a classified ad for "Golden Lab, found near 5th Ave. and Main St." in the "lost and Fond" section, but there would be no way to know which of the papers many readers would be able to decode the message.

Of course the practical problem would be the size and scale of the blockchain. I think Bitcoin 1.0 was only able to do 7 transactions/second. With each message a transaction, and each read requiring the reader to pick out their message from the pile, my above hypothesis would have to be compromised in some fashion to be usable.

Ok, so the main purpose of a blockchain is to get a bunch of computers that don't trust each other to agree on who did what when.

A blockchain gives everyone a "voice", so they can share what they heard. But it can't be the sort of voice we have in the real world, because one computer can easily impersonate a million computers. In the case of Bitcoin, your "voice" is your computing power. Your computer might be able to impersonate a million computers, but your CPU cannot do the work of a million CPUs. So it is nearly impossible for single malicious computer to "drown out" all the other computers and insert a false message into the blockchain.

Bitcoin has a limit to the number of transactions per second because it wants computers to pause and talk to each other before validating a transaction. The delay is a feature, not a bug. This arbitrary limit is designed to self-adjust, so adding more computers won't make the process go faster and removing computers won't slow it down.

That said, computing power uses a lot of energy. Too much energy. So now there are other ways to assign voices that don't rely on raw computing power but still prevent impersonation. This particular messaging protocol uses one of them, it is not based on computing power. But there is still a blockchain that contains everyone's messages, and a malicious computer in theory cannot overwhelm the common consensus. So you can be pretty sure that if a message appears in the blockchain, then it was sent by the person who claims to have sent it.

Note that unlike Bitcoin, this blockchain is not public. It is not like a secret agent placing a classified ad that all can read (but not understand). Even the encrypted form of the blockchain can only be accessed by servers whose users participate in the conversation. If your server has nothing to do with a group, then you cannot glean anything at all about the conversations within the group.

2 more...

No, this is already solved without scam shit tied in.

Eh, I wouldn't go as far as calling distributed ledger tech a scam. Sure, 99% of the current ecosystem is at best digital tulip trading if not an outright scam, but that doesn't mean everything blockchain-related is a scam.

There's valid use cases for what's essentially a distributed database with immutable history (or a "smart contract" system which is essentially a distributed singleton VM with immutable state history), but NFTs etc ain't it. Fintech will probably incorporate some of the stuff that came out of the blockchain craze, but I figure that at best it'll be like Linux; most people who use the internet interact with Linux systems pretty much all the time, and of course Android is a Linux-based phone OS, but very few actually run Linux or even care about the whole concept. It's just part of the infrastructure, which in my assumption some kinds of blockchain-ish technologies might be. Probably just not the public networks people associate with it now, but private / internal ones with limited validator sets etc

People keep saying there’s a valid use case for this but what is it? Basically any distributed ledger would actually perform better, be more secure, and be easier to use as a centralized database.

Basically any distributed ledger would actually perform better, be more secure, and be easier to use as a centralized database.

Performance is relative to what your goals are (extremely high transaction volume isn't always something you need to handle, and also isn't guaranteed to be impossible with a DLT either), and centralized databases / services aren't always the best fit for every problem. Regarding security, well, I really don't see how you came to that conclusion. Guess it depends on what exactly you mean with security?

Real estate is pretty commonly seen as the prime example of a field where a DLT is a better fit than a more "traditional" centralized service. As an example let's say we want a system that could be used to record changes in property ownership, so you need auditable state changes and an immutable history, and you want some sort of guarantees that generally someone who's not authorized to do something to a property isn't going to be able to do it by just issuing a state change (ie writing to the DB.) Your stakeholders are probably going to be the local government, licensed real estate brokers (if that's a thing in your jurisdiction), possibly all private property owners who want to sell their property etc. etc. You absolutely could build this with a "traditional" centralized service that eg. the GOBERMENT (or whoever trusted stakeholder) runs and operates, but then you have a single bottleneck that's entirely dependent on a single stakeholder, and you still need to implement eg. audit trails for state mutations, access control, etc. etc. As I said it's absolutely doable, but many of the things you'd do to build it are essentially just reinventing some sort of DLT but in a monolithic package and without any of the benefits. Take state immutability for example; you'd probably be building some sort of hash tree or chain anyhow but now you have to do both the hashing and the verification and validation manually instead of the infrastructure doing it for you, and it's nontrivial to do right so the attack surface here is not going to be small in a home-grown solution. You'll probably want to require that all state changes (transactions) are signed by a known trusted actor, so you'll need to build that too, so here's yet more attack surface. Also you probably don't want to run literally just a single instance of your database so you're going to want some sort of replication, which may need some legwork depending on the database system used. Compare this (non-exhaustive) list to what your average DLT framework like Hyperledger guarantees "out of the box", where the infrastructure itself gives you guarantees about the immutability of history and who is allowed to make state changes to which parts of the state (in our fictional case you'd want a Proof of Authority consensus mechanism, so anyone making state changes would have to have a valid X.509 cert issued by some trusted CA, but with public reads as property ownership is a matter of public record), which is by default distributed so there's no single point of failure, and is eventually consistent within known parameters and known behavior.

Distributed systems definitely do require more skill to operate so the benefits need to outweigh the costs (and they often do, which is why we eg. tend to use microservices for high volume systems), but I honestly fail to see how for example a project using Hyperledger tools (and there's more than just the DLT Fabric), which are specifically built around privacy and security, would automatically be less secure than a centralized system where you have to build the same features yourself, meaning you just have to trust that you did everything right.

Real estate is a terrible example of where to use a blockchain. Someone gains access to your private key and you just... don't own your house anymore? There's not really a recourse here since it's controlled by the distributed system. On the other hand, the government which is entrusted with the authority to enforce laws can hold onto the this information in a more secure way than the average person. And if something does happen they have the ability to fix problems without issue. I read all these stories online about wallets getting compromised and contents stolen with very little recourse and am confused why I would want the largest purchase that I will ever make in my life tied up in that. Doubly so because that purchase is explicitly tied into the central authority of your government. It's not like cryptocurrency where it can exist externally to the current legal system. Real estate MUST be tied to government in some way.

Your point about how building a secure, central database will have so many technical hurdles to overcome is... odd. I mean, sure it's tough to make a secure database. Your answer is that some blockchain framework has certain security characteristics while ignoring that literally every secure data store that currently exists is running on a central database and just fine at that. Like, what do you think that your bank is using at this very moment? There are multiple companies with well-audited solutions selling and running secure databases RIGHT NOW. You just hand wave away the ability to make secure databases while ignoring that they already exist while expecting us to buy into the promises of some new, unproven framework like Hyperledger. The only thing that blockchain adds is immutability, which is something that I think would be a poor idea anyway.

Lastly, blockchains only work by having users with a financial stake and incentive. With proof-of-work you're staking the cost of the electricity you're spending, with proof-of-stake the crypto you're staking. The point is, they have this whole weird financial structure to keep people running this distributed ledger. How would that even work for real estate? Do you want people with perverse financial incentives muddling with the system that controls your ownership OF YOUR HOUSE? Or the government which is empowered by the people to serve them. And if it fails those leaders face expulsion? I know where my answer is.

would automatically be less secure than a centralized system where you have to build the same features yourself

I just want to hammer this point home one more time. This is a false comparison. You do not have to build these features yourself. Like, have you heard of this tiny company called "Oracle"? Or maybe this really obscure one "Microsoft"? They both make exactly this product.

Someone gains access to your private key and you just… don’t own your house anymore?

Depends on a) what keys you have, b) who even gets to make mutations and c) if the system has provisions for "edit" transactions (which don't change history but say – to put it very simplistically – that eg. "previous transaction x is invalid"). Also it's unclear why you think this is different from a database password being stolen.

Your point about how building a secure, central database will have so many technical hurdles to overcome is… odd. I mean, sure it’s tough to make a secure database. Your answer is that some blockchain framework has certain security characteristics while ignoring that literally every secure data store that currently exists is running on a central database and just fine at that. Like, what do you think that your bank is using at this very moment? There are multiple companies with well-audited solutions selling and running secure databases RIGHT NOW. You just hand wave away the ability to make secure databases while ignoring that they already exist while expecting us to buy into the promises of some new, unproven framework like Hyperledger. The only thing that blockchain adds is immutability, which is something that I think would be a poor idea anyway.

I wasn't saying to throw away existing systems or that banks aren't running secure databases. Jesus christ you seem more intent in just being indignant about me daring to have a differing view about something than actually reading what I said.

You also clearly don't understand what Proof of Authority means and didn't bother to read my explanation, since PoW / PoS are completely different consensus mechanisms and the problems with them don't apply to PoA systems.

This is a false comparison. You do not have to build these features yourself. Like, have you heard of this tiny company called “Oracle”? Or maybe this really obscure one “Microsoft”? They both make exactly this product.

Remind me which Oracle or Microsoft database solution gives you signed state mutations, a guaranteed immutable and tamper proof history out of the box.

Honestly your whole argument relies on you not bothering to read what I wrote and then answering with sarcastic comments based on what you assumed was said. I know you don't agree with me, but try not to act like a twat just because you don't.

Someone gains access to your private key and you just... don't own your house anymore?

Under the current system you don't even have a private key. In some countries it's fairly common for someone to lose their home because someone bribed the official to change the title records.

I think that key management is blockchain's Achilles Heel, but there are some interesting potential solutions

In some countries it’s fairly common for someone to lose their home because someone bribed the official to change the title records.

If the state, with its monopoly on force, says that you don't own land, what difference does it make if it's a piece of paper, a record in a traditional relational database, or a transaction on the blockchain?

Title ownership of a piece of land is only as good as the enforcement mechanism of that title mechanism. Changing from recorded paper deeds to PDFs in a centralized database made sense (and was backwards compatible). Changing from PDFs in a centralized database to a blockchain doesn't actually change the enforcement mechanism, and makes it less efficient. So what's the point?

Obviously if the state doesn't enforce the titles they're useless. Sure if the president of a corrupt country decided he wants your house he's gonna get it. But a DLT would prevent lower level corruption that relies on the benefit of the doubt.

If a corrupt official uses their access to change the PDF title of your house to be in his name, he could take that to court to take your house from you. A ledger would prevent that change from happening, or at least leave a permanent record of the change

A ledger would prevent that change from happening, or at least leave a permanent record of the change

Yes. That's why most western land ownership systems moved to written ledgers in continuous, sequential books since, like, the slow collapse of feudalism 400-600 years ago. Let anyone add to the record but store those records in a way that they can't be tampered with or removed after the fact, and let basically the entirety of the county's land ownership records be tied up in one ledger that all land owners have an interest in properly preserving integrity.

Basically, blockchain doesn't actually help any more than simple/regular digitization does. Which already happened in most places 25-50 years ago.

This is not worth our time to keep arguing. I hope you have a nice day! :)

A trust less system also can aid in stymieing wire fraud in real estate transactions which is shockingly common. Today, someone doesn't even have to have your private key to pretend to be you and steal your escrow funds - just a spoof email, good timing, and a paralegal that makes a mistake

You absolutely could build this with a “traditional” centralized service that eg. the GOBERMENT (or whoever trusted stakeholder) runs and operates, but then you have a single bottleneck that’s entirely dependent on a single stakeholder, and you still need to implement eg. audit trails for state mutations, access control, etc. etc.

So before anyone comes forward and claims that their innovative solution will improve on the status quo, I generally expect them to be able to describe the status quo. And here, you haven't done so.

In the U.S., county recorders allow for anyone to record to the centralized ledger (and this is literally paper technology that long predates computers), and the transactions themselves are validated when necessary to resolve a dispute: one can only sell what they already own, and if they sell something they no longer own it. The law allows for certain types of involuntary transactions: foreclosures, execution, inheritance (where the owner can voluntarily prescribe some rules but doesn't get to control the timing of when those rules get executed, and the failure to affirmatively write stuff into a will means that the inheritance falls back to defaults), divorce, partition, adverse possession, reverter, and then a bunch of special rules that apply to governments like tax foreclosures or eminent domain. And no matter what the actual papers say, ownership of land still must be enforced by a sheriff.

Which portions of this status quo should be decentralized? Or centralized? What would the benefit be?

In my opinion, real estate is the worst candidate for decentralizing the ledger.

Personally I wouldn't be replacing any of that with any cool woo woo blockchain tech; my point was more that the infrastructure used to support the status quo could benefit from some of the features common to DLTs

Well... Banking. I'm not going to write a long explanation like other commenters, but each bank having their independent ledger and syncronizing them each X time, with lots of manual intervention is not optimal. Ditributed Ledgers allow for banks to share the information with each other and for transactions to be done instantly, without dispute issues. This technology is already being used internally within the financial industry, and it's going to stay since it facilitates a lot of internal work to the beenfit of the users.

Edit: As an extra point, these distributed ledgers are not really distributed between everyone, banks store them in secured environments and share them with other partner banks, in a controlled environment.

Electronic voting, maybe? But for most cases a transparently ran centralized ledger should work better.

electronic voting is a bad idea regardless of any blockchain integration

Voting on a blockchain is a great way to enable outright purchasing of elections. If I can prove I voted a certain way, I can sell my vote.

The use case is people who are worried that the centralized database will become inaccessible.

21 more...

Blockchain is a tool for scammers used for scamming, and has almost exclusively been used for such.

21 more...
21 more...

People are still looking for problems to which blockchain is the solution.

So far we’ve found none.

You're right. A blockchain doesn't solve the double-spending problem, so don't create decentralized payment networks. Let's use something like Paypal instead, you know, the one that will sooner or later merge with this single-letter company.

You can also use Google Pay or Apple Pay, and developers can use their stores to monetize their apps. Just 30% or so commission and the apps 'adjusted' to the stores' rules (to be fair, there are not really soooo many trackers, right?).

Proof of provenance isn't a use case either. Use Amazon servers. Microsoft Azure. They store all the data, and it's safe.

We don't need companies like drife.io or particl.io. We have Uber and Amazon. Centralized services are much better. They are so good for humanity that their companies don't even have to pay taxes.

You’re pointing out plenty of good problems that wasting CPU cycles and lack of authority doesn’t solve.

Maybe if we actually looked harder for a solution instead of throwing one that doesn’t work on the problem and hyping it up to be everything that it will never be - we could actually get somewhere.

I mean it all sounds fine when people spin it, but take a step back and look at the problems inherit to the “solution”.

Just based on your phrasing and tone I’ll probably never convince you, but don’t trust me. There’s plenty of people out there who’s described the problem way better than I ever will.

And there are solutions to the problems you point out, they just don’t involve useless computing and executing arbitrary code.

But if you really want to get into fixing these problems you need to get involved with policy (ie. politics).

We need to fix politicians being elected thanks to corporate capital, both direct and indirect.

We need to fix tax regulation globally. We need to stop the race to the bottom where companies incorporate where they can funnel money back to the mothership without paying tax.

We need to fix education, so people get a clue and don’t elect corporate puppets or flat out fascists.

We need to fix healthcare.

We need to fix environmental policy, and thanks to the environmental policies for the last 200 years, the environment as well.

Heck, we even need to fix the Internet.

And all the idealism in the world - the idealist blockchain crowd becomes useful idiots because they’re busy with something that won’t work out (instead of pushing the world in a better direction).

I do however highly recommend a few talks with Larry Lessig:

https://youtu.be/mw2z9lV3W1g

https://youtu.be/PJy8vTu66tE

And on DMCA (you may want to start with this):

https://youtu.be/7Q25-S7jzgs?si=RJniq02TSd7vTOPw

I would beg to differ. It seems to be pretty useful for Software development. After all git repos are Blockchains. That being said: use a solution that fits your problem, don't try to adapt a problen to your solution. Thats something a lot of the crypto- or AI-bros are apparently misunderstanding

After all git repos are Blockchains

No, git repos are merkle trees. Blockchains happen to build on merkle trees. Git is not blockchain.

I suppose it depends on how exactly you define a blockchain. If you add distributed consensus algorithms and a requirement for BFT resistance, then it clearly isnt. Its the usual issue with definition...

The definition isn’t the problem. Git isn’t blockchain, never was, never will be. Thank ~god~ Linus

Since a definition is descriptive, not prescriptive, I think it's paramount.

I have to wonder if it's a solution looking for a problem or a matter of people trying to just throw stuff at a wall and see what sticks.

I think it also probably has to do with the sheer number of people trying to create something that every one of them has to learn that just because something exists, doesn't mean you have to use it. They end up just building it hoping that people will come to use it, but sometimes you gotta learn the hard way that it isn't always the case.

Pretty sure the first guy trying to pitch money faced an uphill battle. But at least it was tangible.

4 more...

Fuck no. What is better is p2p, or federated. No Blockchain is needed, and this is one of those examples where Blockchain is jammed into something where it really doesn't need to be, nor should it be. The last thing we want is for our encrypted messages be permanently stored. Element is federated, and they're working on getting it to be p2p. Some nerd will probably mention XMPP too.

I disagree here. with p2p/federated you have to worry about if your microprovider goes out. I think blockchain would be a useful way to keep a users preferences and to keep usernames distinct.

p2p has no middle man. There's nothing to go out. Blockchain is a literal plague, especially in this scenario when a simple database can handle this. MXIDs already provide distinct usernames. Preferences are often stores client side.

You do not need to burn a tree, push a Ponzi scheme, and make this data permanently public to solve this. That is a terrible idea, and any solution you come up with will be always better without a Blockchain.

I don't think you get it. With a distributed ledger your username could be unique. sorta like the digital art pieces. So if your instance goes down you register at another one with your token and it recognizes you and associates you with everything it conceivably can (some stuff may only have been saved on the instance which is gone). So if the new instance has magazines you interacted with it should still be able to see comments as yours and such.

Buddy wait until you hear about pgp keys or identity keys in general. No ponzi scheme and tree burning required!

Again, there's always a solution that's better and doesn't need the blockchain. Blockchain is literally never the answer unless you're trying to kill the environment and scam others all in one go.

tree burning is bitcoin specific implementation. distributed ledger does not rely on processing power being wasted for no good reason. Believe me I don't like bitcoin or its ilk but am fine with grid coin for example. pgp keys are for authentication and don't store information. distributed ledger is not for authentication its for just like it sounds. keeping a ledger.

The blockchain Is not public. It can only be accessed by nodes whose members are in the channel.

I'm curious whether without a blockchain there is a solution that (a) allows users to access all their encrypted messages even if any individual server goes down, (b) preserves a record of all communications/edits, and (c) is resistant to record tampering by a malicious server admin.

Yeah it's called storing things client side lol.

Also the whole point of encryption is that it can't be tampered with by a middle man. We've accomplished all of that already.

Storing client side isn't good enough, your records could be lost or destroyed. That's why people use Gmail.

And it's not just third parties, what about untrusted recipients? For example, how do you prove you sent someone a message on a decentralized system?

you can store things encrypted

also do you know what identity keys are? We've solved that decades ago with pgp keys lol

Even if it's encrypted, it can be lost or destroyed if it's stored client side.

I know what identity keys are, but they don't solve the problem. If someone says they didn't receive your message, the best way to prove you successfully sent it is to use a distributed ledger.

Yes there is??? Do you know what a read receipt is?

Again, storing messages on the blockchain is a fucking terrible idea. I don't need to store the dumb memes my friends send to each other eternally on the blockchain, nor does anyone give a shit. If it's important enough to want to be saved, you do this new technique called a damn backup.

I don't want to open myself up to my key getting hacked and my entire life history's messages getting leaked. I don't want to open myself to someone stealing my device where my key is stored and having indefinite access to all my past, present, and future data. I don't want to leave my data publicly available with all the metadata and message sizes to see for any unknown third parry, and to who is being sent what to whom. I don't want to be vulnerable to potential encryption breaking techniques in the future. I don't want to deal with the gas cost, the huge amount of latency that would make real time chat unviable, and the insane amount of overhead to solve an already solved problem with an objectively worse solution in every possible way.

These are problems that don't need to be solved with blockchain. Every problem you're suggesting has been solved decades ago and for absolutely free. You are dense as hell and aren't even attempting to look at the already existing technology that has already solved this. Fuck out of here crypto bro.

Do you know what a read receipt is?

That doesn't solve the problem. If you don't get a read receipt, then you can't prove you sent the message. And if the recipient doesn't want you to be able to prove you sent a message, they can disable sending read receipts.

This sort of system is not meant for your use case. It is not meant for memes or other things nobody cares about. It is meant for people who need an auditable permanent copy of their communication.

For example, businesses sending orders, contracts, etc to each other. Or lawyers sending documents to each other. They need systems that are private, not susceptible to central server failure, yet nevertheless auditable in case of an untrustworthy recipient.

If a lawyer sends a time-sensitive letter to opposing counsel, the recipient must not be able to claim, "You did not send it to me on time". Blockchain is a good solution for such needs.

I don't want to leave my data publicly available with all the metadata

Did you read the paper? This isn't Bitcoin. The metadata is not available to the public.

This is such an obscure situation that doesn't even need to be solved with blockchain. Look at the article being posted. "Messaging network for safer communications", which now apparently turns to just a single situation where a lawyer needs to send a time sensitive email and needs to prove it was sent? Which again, doesn't actually even solve the problem. In this case, your blockchain ponzi scheme email can easily get caught by a spam filter. You've now turned the use case to some global read receipt system, which is dumb as hell and something nobody needs.

This use case literally does not exist. It can also be solved by a simple email server. A business that wants to keep logs of all their messages being sent out or received can store everything on their server with inbound or outbound emails. If in the super extreme scenario where a lawyer sends an email and the counsel ignores it, they can get in a lot of legal trouble for lying and would just get delayed. They lawyer can also prove they sent an outbound copy on their email server. What do you think needs to be "auditable" in communication? A business sending a damn receipt does not need this solution, that's the end user for their email being valid. A lawyer sending private documents to each other want the literal last thing to be on a fucking public cloud server that is invisibly accessible by any fucking third party. Do you hear yourself? Are you a real person??

Literally none of these obscure scenarios you're trying to come up with even need a blockchain solution. You should recognize how hard you're trying to justify this as it being a dumb fuck solution. Despite all these issues you're apparently inventing, we use our existing technology every day and none of these are issues. You're coming off more like ChatGPT then a normal person.

I just gave you one example of a use case. It's hardly unique. There are plenty of time-sensitive messages sent in business settings, and plenty of people who don't necessarily want to acknowledge receiving them.

More examples, off the top of my head:

  • Manager tells worker they need to cover an emergency on the weekend, worker claims they never received the message.

  • Business wants to cancel a work order, contractor shows up and says they weren't properly notified of the cancellation.

  • Supervisor sends disciplinary note to employee before dismissal, employee says it was never sent and then claims wrongful termination.

And of course, this has nothing to do with email. So if you set up a "spam filter" that deletes your boss's messages, that's on you. They know they sent you the message, even if you delete it or otherwise pretend they didn't.

This is about an independent audit trail, not "keeping logs". Your personal email server doesn't count, because you can alter the log to show whatever you want. Nobody is going to take your word for it.

Finally, it's pretty clear you have no idea how this system is supposed to work, because you keep claiming that documents are "accessible by any third party". You do understand that not every blockchain system is public, right?

2 more...
2 more...
2 more...
2 more...
2 more...
2 more...
2 more...
2 more...

The blockchain Is not public. It can only be accessed by nodes whose members are in the channel.

So, federation across channel participants, but with blockchain instead of a "shared database"?

Yes, that sounds like their goal.

Blockchain is used to prevent a malicious participant from altering/corrupting records.

2 more...
2 more...

I disagree here. with p2p/federated you have to worry about if your microprovider goes out.

This Quarks protocol still seems to require reliance on "nodes," which is the same thing as a federated service, with extra steps. It's more overhead without any of the portability you want.

oh sorry. I was not saying in general, not that this implementation is good. I could see the distributed ledger being used though to good effect. Unfortunately it rarely is.

Same thing with centralised services only that you have no options to choose from

2 more...
2 more...

retain control

Notably, in Quarks, every user operation and information exchange that takes part on a channel is carried out via the ledger's so-called smart contract. In practice, this means that no-one outside of a channel should be able to send or read messages on it. In addition, all messages on the channels cannot be altered or edited, yet they can be audited, meaning that users should be able to derive information about when they were created, sent, delivered, and so on.

Ah, yes. I definitely want anyone in the world to figure out who I'm communicating with by checking the timestamps of when various messages were delivered. Much like how the "anonymous" Bitcoin could be pretty easily de-anonymized just by checking where various bitcoins go and inferring who those wallets likely belonged to.

Unlike Bitcoin this ledger is not open to the public, it only exists on the nodes containing group members.

And everything in the ledger is encrypted except the timestamp. So without a decryption key, you could tell when messages were sent but not who sent them.

Ah, gotcha, I may not have read carefully enough. I do see how an auditable decentralized trail of messages and any edits made might be useful for certain very sensitive communications then.

What the fuck do encrypted messages need a ledger for?

To get governments interested in it... for tracking it's own netizens... because just about everyone is dealing with CSAM!

How is this better than a normal messaging protocol like Matrix? What does blockchain add to the solution?

I'm not entirely convinced this needs a blockchain. I guess Hyperledger (Fabric, I'm assuming) is a handy way of guaranteeing a total order for a channel's messages / events and making sure history is immutable, but it seems a bit unwieldy for a distributed messaging app despite being somewhat modular.

Most of their goals aren't specifically dependent on anything blockchain-like, and the ones that are seem like they could be implemented in a much "cleaner" way than having to bring in Hyperledger and all that it involves

Entirely overengineered. Redundant with better solutions. This is being pushed for hidden reasons.

There are lots of knee-jerk reactions because people saw the word "blockchain" in the title. It's as intellectually lazy as the shills who refuse to criticize the crypto industry for its shady parts

This just sounds like a decentralized Slack, with a blockchain to ensure all nodes have the same data. The details are sparse, but this sounds like a proof of authority system to achieve consensus between authorized nodes in the network. No cryptocurrency involved. It's just using blockchain as a consensus algorithm between decentralized nodes(which is what it was designed for).

It doesn't say, but since their target demo seems to be enterprises, my guess is that the idea would be companies run their own node in the network, which would allow a high degree of security and be interoperable with other enterprises.

"But you could use a federated system..."

I'm all for the growth of the fediverse, but it still has many problems. If you're running a large enterprise that needs a guarantee that all your messages are synced, in the right order, and nothing has been removed later, a proof-of-authority blockchain is a better system than something federated

This just sounds like a decentralized Slack, with a blockchain to ensure all nodes have the same data.

We've had this since the late 1980's. It's called IRC.

Just what I want, a permanent record replicated everywhere for every flippent thing I say. Hard pass.

Blockchain is a solution in search of a problem. And it hasn't found one to solve yet.

So, if I understand that correctly, the user is now the target instead. Is that better?

user endpoints are always going to the point of failure. Blockchain or not. I think even the matrix foundation peeps mentioned something like that.

Valid point. I feel uncomfortable with the shift of focus this should bring. I'll just put it that way.

I'd much rather have a full peer-to-peer solution like Veilid

The cult of the dead cow has recently announced promising projects. I'm also looking forward to them.