Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)FL
Posts
0
Comments
466
Joined
2 yr. ago

  • He did more than make noise:

    While the woman was on the phone with police, Donofrio broke a glass window on the front door "and reached inside to manipulate the doorknob," at which point the male resident fired the shot through the broken window

    Regardless of what you think about gun laws, I think the resident had good reason to be concerned for his safety.

  • If some library decided to infringe copyright then it could most certainly be sued for compensation under the Takings Clause.

    Government has a Constitutional obligation to pay for any private property it takes, whether it's land for a new building or intellectual property.

  • I certainly do not understand what concept of fucking justice that is related to.

    This concept of justice:

    higher scores will be given to projects that are likely to retain collective bargaining agreements and/or those that have an existing high-quality, high-wage hourly production workforce, such as applicants that currently pay top quartile wages in their industry.

  • 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.

  • 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.

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

  • 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.

  • 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.

  • 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.

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

  • 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.