/ipfs/anon ID: 269956 IPFS + Bittorrent Index May 25, 2018, 1:15 p.m. No.9   🗄️.is 🔗kun   >>23 >>24 >>27 >>28 >>29

As we all know, we need IPFS file index sites like what bittorrent has. Eventually I might make a python GUI/CLI program for creating torrents and IPFS hashes (don't expect anything soon). I need a desktop GUI wrapper for people to submit content to the decentralized index I designed.

 

It uses bitmessage as a submission method and IPFS for database syncing. The content is completely separated from any frontend. Anyone can spin up or shut down frontends locally or publicly hosted on a VPS. The only thing that has to stay up is the admin's bitmessage monitoring/publishing program. Since new submissions and the database doesn't depend on IP addresses, and bitmessage messages stay in the network for days, it can be hosted from any computer and can hop from computer to computer with very little impact on the system. One of the goals is to function in an IP address independent way.

 

For the database I initially thought of using a blockchain to sync the data. Then I realized a few spammers could irreversibly (besides hard forking) bloat the chain to inconvenient sizes. Plus I couldn't deal with deleting real illegal stuff like cp which would be a big problem. Then I turned to IPNS. Each new submission through bitmessage would be a new self describing JSON object file. This has the advantage that all previously synced users would still be sharing all previous content even when the database changes. The admin can also delete JSON records and sync that with peers. For this, peers will have to run a sync script that periodically (every 5 or 10 minutes) checks for an updated address from IPNS. The script would use ipfs ls to compare the previous sync's content to the current content using diff and would download/pin/remove/delete files accordingly. This creates a distributed one-way sync using IPFS. The coolest part though is that the program would also convert and insert or delete the synced JSON records into SQLlite (or any other SQL DB) so it can be easily used from any program, like a web frontend. Of course everything would be modular to support multiple databases and frontends.

 

So there are three components to the system. First, the desktop GUI/CLI that uses bitmessage and IPFS (they would be started as daemons and accessed through their APIs) that allows users to create torrents and IPFS hashes to submit to the system through bitmessage. I'm thinking of a simple python Qt GUI for users to start. Index sites would provide submit.html, report.html, modify.html, and remove.html files that the program will list and serve serve to the localhost (http://localhost/<my-program-name>/<index>/submit.html). When clicked on it will open the files in your web browser and you'll fill out the form (alpalkajs would be used for easy form generation and verification of user metadata like an enum of categories). The webpage would POST the form input as JSON to the python web server. It would then verify it against a standard JSON schema file provided by the index and do the necessary operations (create torrent and IPFS hashes from the provided file/directory). Finally it would send it over bitmessage to the index's address.

 

Second, the index admin program monitors a bitmessage address for new content, processes them (inserts and keeps track of UIDs, usernames, etc), writes/removes them to/from JSON files, and publishes the updated directory to IPNS. It would have a priority queue so certain bitmessage addresses get processes first (deleting is faster then adding) and could optionally have permissions based on the bitmessage address. One index could want to give users the ability to modify their submissions while another would want to reserve modifying to only admins/mods. It would broadcast a bitmessage message every time it accepts, rejects, or modifies/removes records to give users info on the status of their request.

 

(continued below)

/ipfs/anon ID: 269956 May 25, 2018, 1:15 p.m. No.10   🗄️.is 🔗kun   >>39

Third, have a synchronization program that peers use to download and share JSON files via IPFS and construct/keep in sync a local SQL database. Each index would have its own SQLite file. For frontends, indexes have plenty of options. Of course all frontends should be easily user installable so to have as many local users as possible. I'm split about whether to build a modular system where frontend links would be included in the python program (have users go to http://localhost/<my-program-name>/<index>) or leave the frontend implementation the responsibility of the index admin. All data would be queried from SQLite either through their own program or a program such as Datasette (turns SQLite into a JSON API). Web facing frontends can do whatever they want to increase performance.

 

What I'm envisioning is a framework for decentralized index sites to use. There would be a set of basic universal rules but how each index is run is completely up to the index admin. I want to give them as much freedom as possible. Want a closed whitelisted only index? Fine. Want an open index where anyone can submit or modify/delete? Fine. Want an index where anyone can submit but only admins/mods can modify or remove? Fine. How admins run their index is completely up to them.

 

I'm pretty confident this setup could reliably work. Like I said I plan on making it be able to track multiple indexes so anyone can start their own database if they want. I plan on making an anime focused index to start us off. Frontends could even combine multiple SQLite databases to combine content from multiple indexes.

/ipfs/anon ID: 063058 May 25, 2018, 9:18 p.m. No.11   🗄️.is 🔗kun   >>12
  1. Make this an easily accessible website

  2. Make IPFS an installer that has an on-off switch and opens WebUI.

  3. Connect IPFS with BitTorrent, but bundle torrents in big packs such that it is easier to use IPFS

/ipfs/anon ID: 6c8b86 May 26, 2018, 8:58 p.m. No.12   🗄️.is 🔗kun   >>14

>>11

  1. Yes there will be a main website that regular people can visit. Running local versions is highly suggested though for load reduction and self-sufficiency reasons.

  2. Yes the python GUI will have an on-off switch (really process start and kill) and will have a link to open the WebUI to submit, report, modify, or remove. I will probably make site owners integrate with my system so that everything can be listed in one place.

  3. I'm not sure what you mean by this? Given a file or directory, it would make a torrent and IPFS hash.

/ipfs/anon ID: 82efb3 May 28, 2018, 3:21 a.m. No.14   🗄️.is 🔗kun   >>19

>>12

  1. Hosting local versions, mirrors, and decentralize it with multiple communities is important

  2. Definitely, until IPFS/JS is a thing we should resort to Windows installers and Linux widgets/daemons.

  3. If you have an MD5 hash of a Torrent, you cannot isolate a single file easily. In IPFS, every folder is a hash, and contains every hash representing each file.

/ipfs/anon ID: b53025 May 28, 2018, 11:29 p.m. No.17   🗄️.is 🔗kun

https://github.com/richardschneider/net-ipfs-mount

https://github.com/marcin212/ipfs-gui

https://github.com/bogdoslav/ipfs-windows-installer

/ipfs/anon ID: 6c8b86 May 29, 2018, 12:58 a.m. No.19   🗄️.is 🔗kun   >>20

>>14

Yes the infohash (SHA1) of only the top level directory will be included.

 

>>18

Yes. In fact that idea was the result of a discussion I had with him in a previous IPFS thread on /tech/. I made improvements and took a different approach than him in my own solution. I could post a DM vs my solution comparison if you want.

 

I thought of a name but want to buy a domain before anything else. Do Bitcoin accepting registrars really check to see if the name+address you give them is legit?

/ipfs/anon ID: 257f7c May 29, 2018, 1:44 a.m. No.20   🗄️.is 🔗kun   >>21 >>26

>>19

>I could post a DM vs my solution comparison if you want.

A detailing of the difference would be helpful. In particular, I don't quite understand what you mean by the bitmessage integration. Does this mean end users would have to install both IPFS and Bitmessage? What's the advantage over using either the baked in ipfs p2p and/or pub/sub frameworks?

 

>In fact that idea was the result of a discussion I had with him in a previous IPFS thread on /tech/

Yeah that's me, hello again.

/ipfs/anon ID: 82efb3 June 5, 2018, 4:13 a.m. No.25   🗄️.is 🔗kun

>>24

https://hackernoon.com/ten-terrible-attempts-to-make-the-inter-planetary-file-system-human-friendly-e4e95df0c6fa

/ipfs/anon ID: ba3981 June 5, 2018, 3:16 p.m. No.26   🗄️.is 🔗kun

>>20

>Yeah that's me, hello again

Nice to talk to you again! When I get some time in the next few days I'll post a thorough comparison.

 

>>23

>electron

What a waste. He could've easily used webview instead.

/ipfs/anon ID: 9b924d June 5, 2018, 7:11 p.m. No.27   🗄️.is 🔗kun

>>9

We should also add a feature for website archives https://github.com/oduwsdl/ipwb

And let's not forget what we can do to RightPedia and Metapedia https://github.com/jamescarlyle/ipfs-wiki

For Git rehosting of /hydrus/ and other libraries https://github.com/whyrusleeping/git-ipfs-rehost

/ipfs/anon ID: 0d7893 Sept. 10, 2018, 10:38 a.m. No.39   🗄️.is 🔗kun

>>10

>Frontends could even combine multiple SQLite databases to combine content from multiple indexes.

These would function as repos, correct?

/ipfs/anon ID: 708761 Oct. 8, 2018, 4:22 a.m. No.41   🗄️.is 🔗kun

just fork qbittorrent and add a new button to import and download ipfs hash

then I can have my torrents and ipfs in the same client