Notices by p (p@shitposter.club), page 10
-
p (p@shitposter.club)'s status on Thursday, 08-Feb-2024 03:41:45 JST p @silverpill @p @mint @Moon @arcanicanis
> Why?
Data-puns rarely work out how you might hope. It's better for it to be unambiguous. It may seem unlikely that the DID is accidentally generated, but consider a maliciously crafted URL, for example.
One of the things Revolver does is just put an ID in the headers so that, like how IPFS does it, if the data is large enough that it hasn't all arrived by the time you've parsed the headers, you can consult the local storage first. (For example, `curl -I https://media.freespeechextremist.com/emoji/custom/revolvertan.png`.)
> I want to limit protocol changes to IDs because this should make the implementation simpler, at least in theory.
This is a good idea, but extending it when it's an extension is probably the best. If you're sending things based on what you think the other server understands, then that's harder to debug and easier to craft maliciously. Easiest way to do it is to just give everyone what you have (or at least what they ask for) and it keeps it more flexible, so maybe someone does an experimental Pleroma that supports fetching these DIDs but no one is delivering them because they saw "Pleroma" and guessed "Doesn't understand DIDs", or Pleroma starts to fully support them but all of the old posts were delivered without DIDs.
> And we could support even more URI types in the future.
If you do something like adding `"cas":{"ipfs":"hash", "did:ap":"other-hash", "rvl":"third-hash"}`, that might enable implementations to kind of branch off. Or maybe call it "alt" and add whatever Nostr uses to the list. Then an implementation's free to scan the "alt" list and find something it understands, and fetch otherwise.
(Working right now so it is possible I have rushed and have read carelessly.) -
p (p@shitposter.club)'s status on Thursday, 08-Feb-2024 02:52:23 JST p @silverpill @p @Moon
> How blocks are re-assembled into "posts"?
It works like venti, kind of, except that the metadata is stored in the pointer blocks. So the individual blocks where the data is stored, they are nearly unidentifiable on their own, you can safely propagate them without liability. Then the pointer blocks say things like "block $x, size $y, zlib-compressed; block $x+1, size $z, uncompressed" and they're reassembled like that. Unlike IPFS, the block size is 8kB max, so there are more collisions (which are good in this case) and it's easier to distribute individual blocks. Just empirically, it's also much faster to read data that you have locally and acquire unknown blocks, but we'll see how that holds up under heavier use. FSE's emoji and media storage use it (so media.fse is still up and running and it's got most of the uploads) and it's handled the load just fine.
> How node determines what blocks are needed?
The pointer blocks contain references to the blocks under them, so if you have one, you can tell what blocks are needed to assemble the full chunk of data. Someone performs an activity, and effectively they manufacture the blocks required, then sign the pointer block and a sequence number, and new blocks are fed to the rest of the network. The big hosted nodes can eat everything they hear about, smaller nodes only fetch blocks that are required to reassemble the streams of people that someone on the node is interested in, and individual nodes don't have to keep anything but blocks that haven't propagated. Usually, keeping them in memory is fine, but this might not be the case once it gets heavier use. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 23:28:56 JST p @silverpill @p @Moon
> From what I heard, you split objects into pieces and transfer them via IPFS... Is that correct?
No. Kind of. IPFS is an alternative supplemental channel that works transparently by fortuitous coincidence: IPFS and Revolver both use SHA-256. So Revolver can kind of optimistically request blocks from IPFS and it can send them to IPFS as a fire-and-forget, but I have IPFS disabled on most of the nodes because it slows down the network. It has its own protocol for moving the slush and it can make use of side-channels, like it uses HTTP as one side-channel, so it can fetch blocks over HTTP/HTTPS/Tor and probably I2P, and eventually other stuff. The idea is that it should be easy to move data into and out of your node regardless of network-level censorship, so you set the protocols you want your node to speak and it looks for peers that advertise that they speak that protocol. IPFS is almost only accidentally a transport layer because it's a pluggable backend layer that happens to speak to a network; there's no reason it couldn't support Tahoe-LAFS or something as another storage backend (venti is planned). For network propagation, at some point it might even support bittorrent at some point (looking into it is planned).
> You can use regular HTTP to deliver them and fetch them, but you can also use other transports.
This is a good plan. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 23:20:05 JST p @silverpill @p @mint @Moon
> Yes, but server can send different activities to different peers.
This is behavior that I wouldn't want to rely on. You end up with bad auto-negotiation and someone checks a header instead of probing for capabilities and that ends up the way `User-Agent:` ended up, plus it compels you to keep a lot of state around.
> Software that supports FEP-ef61 would recognize a resolver path and process the object accordingly.
That makes me nervous. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 08:33:22 JST p @silverpill @Moon @p I do really like the aliases bit. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 08:33:22 JST p @silverpill @p @Moon Initial glance, looks like it. I was going to add supplemental keys named with an "rvl" prefix, so like {"url":"...","rvlid":"..."} like I've been doing with the HTTP headers, but that was going to be slightly later. Same thing with the attachment digests.
It just occurred to me now that I should probably have been subscribed to the RSS feed for the FEP stuff; the way that stupid hardware has been (and other personal things like the dog's cancer and a few other things that have been resolved finally) I had no time for my own stuff so I slacked on following the Mitra development. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 07:34:08 JST p @Moon @mint @p @silverpill W3C specs born after 1990 don't know which part of the URL is supposed to be opaque to the client and which is supposed to be opaque to the server, they only know produce ill-conceived wishlist, make everyone else charge they phone, eat bandwidth, and lie. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 07:30:48 JST p @mint @silverpill @p @Moon It beats the Mastodon version, using fragment identifiers to address JSON attributes, like "#main-key". -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 06:59:19 JST p @pernia @p @Moon Reality is that which, when you stop believing in it, doesn't go away. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 06:57:04 JST p @pernia @p @Moon I say weeks and I mean weeks. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 06:44:27 JST p @p What is that image from? -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 06:44:24 JST p @Moon @p Give it a couple of weeks and we won't need to. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 06:30:54 JST p @threat @moth @sysrq It tastes like polystyrene person-that-didn't-know-it-was-about-Scientology-because-they-just-saw-it-on-MySpace-or-whatever-people-were-using mask. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 06:30:53 JST p @threat @moth @sysrq -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 04:27:34 JST p @amerika @mint @p Revolver: the great equalizer. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 03:55:29 JST p @astheroth Hardware failure after hardware failure. Gonna just resurrect it as Revolver instead of replacing more parts. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 03:55:28 JST p @astheroth That is good news. -
p (p@shitposter.club)'s status on Wednesday, 07-Feb-2024 03:55:21 JST p @astheroth
> went to the void
All the posts will be imported, except DMs and possibly followers-only posts. (Revolver doesn't have followers-only; it is used as a privacy setting, which is a mistake, but that is how people use it so I may have to avoid importing them.) Your posts will be immortal shortly.
> Anyways, I hope that the failure steams up revolver development somewhat 😅
The idea is that, instead of spending a couple of weeks trying to dx and repair the box, I just spend that time hacking on Revolver and then get new hardware when I have the cash, and then instead of having this overpowered box trying to power Pleroma attached to a 500GB database, I have something more modest for Revolver, which is tuned to scale a little better. (Don't get me wrong, Pleroma is great and I would not have anything to tune if I wasn't using Pleroma. Effectively, I'm cheating by using figures I got from Pleroma to do my ground-up design, so I have an advantage that the Pleroma devs didn't have, because Pleroma didn't exist when they were doing their architecture.) -
p (p@shitposter.club)'s status on Monday, 05-Feb-2024 15:35:18 JST p @dcc @p @sjw
> porn needs to be scorched
Pork. Ahem. -
p (p@shitposter.club)'s status on Monday, 05-Feb-2024 14:11:43 JST p @dcc @sjw @p I have spent a lot of time impersonating a two-ended geyser and porn needs to be scorched to avoid giving me flashbacks.