ux improvements

[okdistribute]

Improvements to make syncing multiple dats a first-class property of dat. This is a proposed UX for integrating dat-store style Daemon into the CLI:

$ dat run-service --config=myConfigFile.ext 
Starting dat service...

• New feature: Starts a dat-store service (and gateway for local connections?)
• myConfigFile.ext has some basic networking options, most importantly, the port
• also, dat install-service

$ dat create /Users/okdistribute/Dropbox/videos 
$ dat sync /Users/okdistribute/Dropbox/videos 
$ dat share /Users/okdistribute/Dropbox/videos 
$ dat /Users/okdistribute/Dropbox/videos 
Created dat ...dat://ab234bf2e...
Sharing dat on the network

$ dat clone dat://ade32bfg2e... /Users/okdistribute/data/nature-report 
$ dat dat://ade32bfg2e... /Users/okdistribute/data/nature-report 
Downloading... 
Done.

• Difference: for create/share/sync and clone, service knows that this dat was created
• Difference: the service starts watching for changes and serves the dat history on the network

$ dat stop /Users/okdistribute/data/nature-report
$ dat stop dat://<key>
Stopping syncing...

• New feature: if you want the service to stop sharing the dat
• If the service isn't running, say it isn't running

$ dat info

• New feature: Opens local website for dat-store that has a list of your dats and allows you to view progress/control their versions/etc

The future of dat sync and share

sync and share are confusing right now and do different things. instead, they ought to do the same thing and reduce the scope of the cli.

[cblgh]

misc thoughts, updated constantly nota bene, some points might contradict others

it would be nice if..

• the cli consumed stdin in standard unix fashion, as that has proven to be a powerful pattern when used appropriately (and lets the other tools and programs that exist do the heavy lifting)
• we had user personas defined publicly, i'm sure CS&S have a lot of wisdom to share based on their meetings with academics and their prowess in the terminal (i.e. who is the cli for? are uxers expected to have git experience? people who have torrent experience?)
• the semantics mirrored git when it makes sense (dat init for example)
• you never needed to create a shell script to catch the crashing dat daemon process (but that the process instead was self-healing, and maybe launched a child it could reboot when it dies)
• you could list and manage the dats that have been created by using the cli
• you could tell the daemon about new dats for it to seed and it would do so without needing to restart
• if using the cli was composable with other tools, able to be used as part of a toolchain

---

actual needs

• starting to sync existing archives by giving the paths to them
  dat dats/p2p-oresund-1 dats/p2p-oresund-2 dats/p2p-oresund-3
• start a sync and be safe in knowing that the process wont crash
• clone and sync/seed a remote dat with one command
  dat --seed dat://1337..7331 dats/jacobs-app
• sync hypercores
  dat cabal://14bc77d..0e99e dats/public-cabal
• create a new archive easily
  dat init dat init dats/new-archive
• create a new archive and start sync immediately
  dat init --seed

[okdistribute]

so dat init already exists! yay dat init --seed should be the same as dat </path/to/folder>

dat run-service
dat install-service
dat add dat://<key> dat://<key2> dat://<key3>

dat share/sync /path/to/folder /path/to/folder2 /path/to/folder3
dat clone dat://<key> /path/to/folder

• if you have a service running, the service handles the swarm/sync for you in the background

daemon

• similar to sbot, postgres, ipfs daemon
• runs in the background
• manages swarm so you only have one port open (fixes the random port opening issue for sharing many dats)

sync and share should be the same thing

started this work on the https://github.com/datproject/dat/tree/dat-v14

[RangerMauve]

Yeet