Show newer

Thinking of getting some computer speakers... so that we don't have to share one set of speakers between two computers. I have no idea what to buy though. Unless anyone here has any I guess I'll just pick some random ones that look good. Most aren't very expensive...

Wait... if you're sending some message to several peers, and you get that list of peers from a database... then how do you do... that? If you only get partway done, and you rollback the transaction and try again, then you'll send the message to some peers twice. But you can't save your place in the query, because if you rollback, then anything you save gets lost. One transaction per peer? A table of... peers that haven't got messages, which slowly empties?

Cy boosted

So here's an interesting question (?)

Have you ever heard of a privacy respecting, fediverse service or at least foss, for dating? For meeting other people online without ads and privacy horror stories?

#dating #foss #fediverse

Oh jeez, I forgot about the mandatory 0'd hash in the first block of a blockchain when I calculated. It's actually 1,954,144 bytes of overhead for the blockchain, a difference of 32 bytes, or 0.0016% overhead for hash trees. And again, less overhead for smaller. Anything less than 80 megabytes, there is no extra overhead at all.

Show thread

In the 4G example, the hash tree will fully fit in 30 blocks. Those blocks can be given higher priority, more replication, more redundancy. In contrast, blockchains have 1 hash in every single block...thing, so unless you can apply the same replication to all 61,065 blocks, you're at far greater risk of catastrophic data loss.

Show thread

Hash trees are random access. They can be swarmed. Once you have the tree, you can validate any of the blocks in levels below. That's why bittorrent can be swarmed, because it uses hash trees not blockchains. You can get the blocks from anyone in any order and still reconstruct the file, in-place. If a block gets lost or corrupted, you only lose a tiny amount of blocks, and can re-request exactly what you need. Plus hash trees take up orders of magnitude fewer blocks...

Show thread

Hash trees do have some overhead: the file, plus the size of the tree. But blockchains also have overhead, just intermingled with the data of the file, plus their blocks must be smaller, so more hashes, more overhead. I calculated for a 4G file, 65K block size, 32B hashes, blockchains have 1,954,112 bytes of overhead, while hash trees have 1,954,176, a difference of 64 bytes, or 0.003% more overhead. Anything smaller has even less extra overhead.

Show thread

So if one of the things gets corrupted, you have to reject all the previous things I'm spamming at you, since some adversary could have replaced them all with garbage data or something. If the network is flaky and drops a thing halfway through, I'll spam 2 gigabytes at you, which you reject, and then you request the new tail of the chain and I have to spam 2 gigabytes at you again, a total of 6 gigabytes, assuming no further issues.

Show thread

Blockchains take for f-ing ever to request. I could spam the whole chain at you though, and you'd accept it as fast as you could verify each "thing," one at a time. You can't rebuild the file in-place, because you'd get 32 byte hashes stuck into it, so that's hard to deal with. But the real damning flaw is that you can only verify the chain in reverse sequential order. You can verify none of the previous things, until you receive all the things ahead of them.

Show thread

With a , I break the file into 65,503 byte blocks, and then add 32 empty bytes to the first block. Then I take the hash of that... thing, and add those 32 bytes to the second 65,503 byte block. Then add the hash of that to the third, etc. You can reconstruct the file if I send you the hash of the last thing, and you request the previous thing, then the previous one and so on until you get a hash that's zeroed out.

Show thread

With a hash tree, I break the file into 65K blocks, and get the hash of each block. Great. Now how to get those hashes and their order to you? Well, I make a list of the hashes in order, but what if that list is bigger than 65K? That's the "tree" part of it. You break that list up into 65K blocks, and make a list of their hashes, drastically fewer. Soon you'll have it down to one <65K block with 1 root hash, that you can send to me, and I'll request the rest.

Show thread

are f-in incredible and here's why. Say you make a protocol that blocks any single transfer that's above 65K (0xFFFF bytes). So nobody can send you anything bigger than 65K, without you being able to verify its hash. Obvious limitation: there are files bigger than 65K. With a hash tree you can accept that limitation and still receive a 4 gigabyte file, with only 0.04% overhead. You could use a hash *chain* (aka a blockchain) but that's inferior for a few reasons...

Short of an outright Sybil attack, which can be defeated by steganography or having just one single peer outside the adversary's control, you can estimate whose version of someone's feed is the legit version by looking at the odds that your known peers are telling the truth. That means you can basically get someone's feed without ever connecting to them, or verifying their identity at all. You can build trust with them, without any signatures or even authentication.

Show thread

Let's say you peer with Alice and Bob, and Alice sends you Claire's feed. You just blindly trust that it's Claire's feed, but then Bob also sends you Claire's feed. If Bob and Alice send you different feeds for Claire, but they also send you their own feeds, you can tell if Bob is lying about Alice's feed. If he isn't, then that's 2:0 odds he's telling the truth about Claire, with only 1:1 odds for Alice, since you can verify she lies once, tells the truth once (her own feed).

Show thread

OK idea. No signatures, no certificates. Deniable authentication between peers, and nothing else, but with relaying. If Alice sends you Bob's feed, you just blindly trust that it's Bob's feed, allowing Alice to MITM you and Bob whenever she wants. Crazy, right? Well, if you're also peering with Bob, then you can tell if Alice is lying...

There is some slight warping and moss at one spot. I was looking at a video that showed flashing as basically just thin sheets of aluminum, you jam under the shingles so that water doesn't go back around the underside of the shingle, and goes down into the gutter instead. Might need slight adjusting of the gutter holder things to keep the gutters straight. I really don't know a thing about it though, just that it seems simple enough.

Show thread

So, with if "followers" is the recipient of a post, then it gets posted to the inboxes of followers, but doesn't appear on any timelines like public, local, or the user's own feed. It will show up in no timeline anywhere, unless the recipient is "public."

So, anyone know how to repair the flashing on a gutter? I got a cold $4500 to make, if I can do it before the "professionals" go make us buy another few hundred cubic feet of aluminum.
She claims water is pouring down between the gutter and the roof but I'm not in front often enough to see it.

Show thread

A nice friendly lady came to our door unsolicited, to give my mother a free estimate on replacing her gutters. In shock, the lady explained that this happened to be the very year our house would fall apart unless we paid her company $4500 to replace our gutters. That afternoon at dinner, my mother very gravely told me we have to replace our gutters now, that she had actually been planning to for quite some time, and the didn't influence her decision at all.

So when you create a new post, your instance takes everyone it knows to be following you, and issues a POST to each of their instances, with the contents of your post. And... that's the only time it ever pushes anything. Thus that's the only time HTTP signatures (spits) are ever used. ...right? Oh, also follow rejections are pushed, I think? There's no way to sign HTTP responses, as far as I can tell, so outbox, followers lists etc will never be signed.

Show older
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!