[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]

/ipfs/ - InterPlanetary File System

The Distributed Permanent Web
Name
Email
Subject
REC
STOP
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
Archive
* = required field[▶Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webp,webm, mp4, mov, pdf
Max filesize is16 MB.
Max image dimensions are15000 x15000.
You may upload5 per post.


| What is IPFS? | Documentation |
IRC on Rizon: #/ipfs/

File: b575d49c1e5f88b⋯.jpg (1.25 MB,1500x1972,375:493,Athena.jpg)

269956 No.9

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)

____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

269956 No.10

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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

063058 No.11

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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

6c8b86 No.12

>>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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

82efb3 No.14

>>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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

8f3ccf No.15

Also can someone bundle I2P functionality with the IPFS windows executable/installer?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

b53025 No.17

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

257f7c No.18

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

6c8b86 No.19

>>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?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

257f7c No.20

>>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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

fb3e80 No.21

>>20

Please if you can, add support for >>>/hydrus/

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

5389b4 No.23

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

82efb3 No.24

>>9

What about this? https://blockchain-dns.info/

Also Blockstack and Ethereum domain names

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

82efb3 No.25

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

ba3981 No.26

>>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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

9b924d No.27

>>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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

9b924d No.28

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

e67281 No.29

>>9

Any updates?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

1a6e96 No.33

Bumping this, also interested in any updates

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

0d7893 No.39

>>10

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

These would function as repos, correct?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

708761 No.41

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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.



[Return][Go to top][Catalog][Nerve Center][Random][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]