Conversation

Notices

1. pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Wednesday, 13-Sep-2023 01:51:24 JST pistolero :thispersondoesnotexist:
   @meowski Sort of. The instance serving these files is not connected to IPFS, but other peers are. But even then, it stores *blocks* to IPFS rather than entire files so they can't just be used as-is.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Wednesday, 13-Sep-2023 01:51:23 JST pistolero :thispersondoesnotexist:

     in reply to

     • ロミンちゃん
     @romin @meowski Can't do venti blocks directly because Revolver uses SHA-256 instead of SHA-1. :alexjonescrying:
     
     The backing store for blocks is modular; right now, there's memory, filesystem, IPFS. Some time after launch I will probably add one that speaks venti's wire protocol, but I want to get it out the door as soon as possible, so for now, the only interaction it does with venti is indirect: the Plan 9 nodes are all using fossil.
   • ロミンちゃん (romin@shitposter.club)'s status on Wednesday, 13-Sep-2023 01:51:24 JST ロミンちゃん

     in reply to
     @p @meowski are you storing venti blocks :l_think:
     Machismo repeated this.
   • ロミンちゃん (romin@shitposter.club)'s status on Wednesday, 13-Sep-2023 02:37:06 JST ロミンちゃん

     in reply to
     @p @meowski so it is a fossil fs mounted on top of ipfs? You have things like /objects/uuid and /users/uuid I presume?
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Wednesday, 13-Sep-2023 02:37:06 JST pistolero :thispersondoesnotexist:

     in reply to

     • ロミンちゃん
     @romin @meowski No, just the Plan 9 nodes' filesystems are fossil, so that gets sync'd to venti, so the blocks end up in venti. Revolver just treats fossil like any other filesystem. Later, I'll add direct venti support but I don't want to push back the release just to do that. (Maybe I will get bored and do it anyway if I am frustrated with some other part of the codebase and wanna work on it over a Saturday, maybe someone else will add it after it's released.)
     
     IPFS was added as a proof of concept for propagating Revolver's "slush" (the blocks that propagate through the network) and it works but the nodes that use IPFS run way, way slower (even though Revolver's use of it is the equivalent of `ipfs block get` and `ipfs block put`; at least `ipfs block put` should be really fast). The concept was proved, but IPFS isn't critical, it's just tangentially related to the project: it is one of the ways for blocks to be stored and to propagate but it's optional for both of those purposes.
     
     
     
     
     
     (The API endpoints are /api/v0/block/get and /api/v0/block/put . You'd think "put" would be really fast because it just needs to store the block and probably do some bookkeeping, and then anything else it needs to do, it should be able to do asynchronously. I don't know why it's slow but their code is a mess: https://freespeechextremist.com/notice/AHLVZSb6i3WDgWSasy . I'm actually glad that one of the dependencies of their libp2p required CGO, because I was planning on using as much of their code as was practical, but no CGO on Plan 9. So I dropped it instead of making heavy use of it and then having a disaster down the line where I had built up all this code that relied on their libraries and then bugs and slowness hosed me. It would be really exciting if it was viable.)
      likes this.