fe.settings:getUserBoardSettings - non array given[pone] - Endchan Magrathea
. Hardware suggestions. Recommend using medium or high tier stuff. May not work very well on low end tech. An upload speed of >5MB/s is nice, same with using a RAM disk or SSD. It also works in 32-bit computers and in BSDs (so I've heard).
. Software suggestions. Use IPFS Desktop for GUI (according to some this not so good) and use kubo for CLI. Recommend using a filesystem that doesn't suck. NTFS has screwed me multiple times (including in regards to an old version of kubo) and is bound to Windows. Use ext4 for 32-bit and 64-bit computers. Use ZFS/btrfs/whatever for 64-bit computers. If you have to use MS Windows, maybe it is better to use FAT32 instead of NTFS. I think FAT32 has a 4GB max file limit. Not a problem in IPFS because the repo won't contain files larger than 1 MB in blocks or larger than ~100MB(?) elsewhere.
. Accessibility. ipfs:// is faster than https://ipfsgateway.com/ipfs/. Some gateways work better than others. Also, mount it to folder "/ipfs" or somewhere else for arbitrary file/folder access (more on that below). Ever use Apache HTTP Server for accessing local files anywhere on your local network? You may see that it is slow sometimes due to I/O saturation if your storage device is also doing something else. Apache web server can also be used with IPFS, and in some cases that could help you access the data quicker. Simply run "ipfs daemon --mount" (gotta publish whatever to your IPNS name beforehand) then make a symlink in your web root folder to /ipfs. In /var/www/html/ (web root) you can make everything password-protected; like if you live with other people and are worried they might be going through whatever is accessible by your server software. However, locally, Apache uses HTTP and not HTTPS, so there is the privacy concern of it not being encrypted. This is a concern because if you live with a techie maybe he will be reading your basic HTTP data which is plaintext/plaindata.
. Dynamic data. Use IPNS. Don't lose your private key as specified in the file "config". Maybe backup your key. Don't share your key in an unencrypted way. Filebase can help with IPNS, but they don't tell you the private key in one method.
. Sharing. Seems you gotta talk to people in popular places like Discord (cringe) or something in order for anyone to also pin/host/store your stuff. Of course they will only get/host what they are interested in. Being an antisocial, loser, I have been trying less to tell users who may be interest in my stuff about it. Maybe I am afraid that they will call me an autistic faggot. Or, I don't feel like taking the time to got to some Internet place for IPFS users (or some other popular/mainstream place) to tell them about it.
. Backups. IPFS repos use a fairly simple structure. Because they are simple, it is probably easy to backup stuff. You can rsync blocks from one repo to another. Sync /path1/blocks/ to /path2/blocks/ ("optionally" in non-overwrite mode). Then non-overwrite copy .ldb files from repo 1 to 2. Then pin them in repo 2. Otherwise, backup via CAR files export/import which is faster because it works in offline mode. Or have both repos online then pin whatever is missing in the other one. CAR files can be streamed and imported over ssh; run this (preferably in GNU screen): $ ssh host@10.0.0.1 "export IPFS_PATH=/something; ipfs dag export Qm..." | ipfs dag import --stats. (GNU screen: press ctrl+ad to return to normal and screen will keep running whatever then run "screen -r" to bring the screen session back to the foreground; exit exits screen.)

2/2

 >>/10173/
> offline storage, raw leaves
Raw-leaves seems to use significantly less storage space