67
A decentralized, blockchain-based messaging network for safer communications (techxplore.com)
submitted 2 years ago by to c/technology@beehaw.org
114 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 2 years ago (3 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 9 points 2 years ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 12 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 2 years ago* (last edited 2 years ago) (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago* (1 child)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    you can store things encrypted

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago* (last edited 2 years ago) (1 child)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    You didn't even know what a pgp key was before this convo or read receipts, you have no idea what you're talking about. This is not a real problem and is already solved with outbox emails.

    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.

    Falsifying evidence is a crime.

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

    Lol then the manager will say "why did you not respond", it's on the worker. They're not going to pull up a fucking blockchain, they're going to pull out their phone and say "see, I sent you this".

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

    That's the contractors fault. Blockchain is irrelevant. If they didn't check their email, they're sure as hell not going to check a dumb ass blockchain.

    They know they sent you the message, even if you delete it or otherwise pretend they didn’t.

    Crazy, I wonder how they know that? Maybe because they know they pressed the "send" button, and it's the other party's responsibility to accept.

    Again, none of these situations need a dumb fucking blockchain.

    You do understand that not every blockchain system is public, right?

    https://www.blockchain.com/explorer

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago

    You didn't even know what a pgp key was before this convo or read receipts

    Lol what? I knew what they were, I just thought it was stupid to bring them up because they solve nothing.

    Falsifying evidence is a crime.

    Oh, then there is no need to worry about it, I guess.

    "why did you not respond",

    "Respond to what??"

    they're going to pull out their phone and say "see, I sent you this".

    Then the worker pulls out their phone and says, "see, it's not on my phone"

    That's the contractors fault. Blockchain is irrelevant. If they didn't check their email, they're sure as hell not going to check a dumb ass blockchain.

    Unless, of course, the sender/manager actually didn't properly notify the contractor/employee, and now they are lying to cover their ass.

    Like many disputes, it amounts to he-said-she-said. When it goes to court, the jury will flip a coin. There is a better way.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 2 years ago (1 child)

    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"?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 9 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •