/hydrus/ - Hydrus Network

>>4530

Doesn't Hydrus support application mimes? This shouldn't need a rework at all

>>4532

My complaint is that doesn't solve the problem with all the download links being broken. Ideally, everything would be distributed through something like ipfs with a central repo providing the metadata to tie everything together. I'm tired of having to spend hours hunting down links from dodgy sites, or else having games that just disappear entirely. If I'm correctly understanding Hydrus, it should be possible for it to solve this scenario.

>>4534

Yes, it should.

Hydrus just needs archive support.

>>4536

Incidentally, archive support would also enable Hydrus to handle manga/doujinshi with no further additions. That's not really a concern for me though, since there's already sites that do that. I'm concerned with H-games since there's literally nothing out there right now.

>>4624

Would this permit for distribution to be entirely IPFS-based? As I understand, Hydrus keeps a copy of all files directly in the system on a central (DMCA-able) server, which would likely go under quite quickly. Having IPFS addresses there as metadata is fine, but hosting the files themselves is not. Or am I misunderstanding?

>>4688

It would be nice if hydrus could support IPFS or other distributed systems like this in future.

The hydrus client keeps all files on your hard drive. If you like, you can set up a hydrus server to help share some of those files, but it isn't required. Nor is it great–there are better solutions for sharing files out there at the moment. IPFS is similar–it has some nice ideas, but is still a bit clunky. I expect to do more on this in future.

>>4624

I haven't used or set up a file-server in hydrus so I don't understand how they work; I'm somewhat familiar with IPFS. With that in mind bear with me. It seems like replacing a centralized filerepo with an IPFS hosted one should be possible, although somewhat strange.

The repo would still have to act as a normal centralized repo for writing but also offer read only access via IPNS/IPFS.

With something like this the location of the server can remain a secret, as such it should be less susceptible to DMCA as long as only privileged people know the write address, a user could even go as far as to disallow internet access on the file-repo port but not the IPFS port. So the reads can be distributed, but the writes have to remain centralized. (There are methods being worked on in IPFS for real time distributed communication but they're not refined yet)

I'm just going to throw ideas out there in case they're useful.

Splitting post because server error

>>4624

>>4749

hydrus already has the ability to use its own file-repo and knows how to create IPFS directories as well as download files via IPFS. I don't know what kind of transactions have to take place between the server and client for the file repo but if it's not too dynamic you may be able to do something like this.

Client:

In the remote services->file-repo instead of pointing to a domain, point to an IPNS(not IPFS) hash i.e. "/ipns/*hash*"

Maybe have a checkbox for "IPFS hosted" so you don't have to do special parsing to guess if it's a domain or a multihash, alternatively separate this into its own service.

Server:

Set up a typical hydrus file-repo, doing whatever is normally done

Depending on how file-repos work, do one of the following, if clients sync everything at once, just create an IPFS directory that contains all the files in the repo as well as any hydrus specific metadata for the client.

If file-repos let you download individual files on demand just replace the target address and download method with an IPFS hash.

Regardless of which one of those you use, create an IPFS hash containing the data the client needs, then publish this hash via IPNS

The client can poll this periodically in the same way they do now, pulling down the metadata allowing them to either retrieve all the files or receive the hashes to retrieve them individually depending on how things currently work.

>>4749

>>4750

Right, exactly what I'm thinking. I'm operating under the assumption that at some point within Hydrus, the system identifies unique images by their hashes. That being the case, it should be possible to instead refer to them by their multihashes. Then, if it's a multihash get the file from /ipfs/<hash> instead of from the server. The server for its part continues to behave as usual, but with the actual downloading of files part cut out in favour of only transferring the metadata parts, the client then being responsible for actually grabbing the files.

IPLD is also worth looking into, rather than having the data be pushed into some sort of unix directory structure.