turn-key Dockerfile

[ghost]

Get up and running quick and effortlessly

• docker build -t follow -t follow:latest .
• xhost +local:nobody
• docker run -it -d --rm --network host follow:latest

note: if you are using --userns-remap this will not work for you,
alternatively you can run a separate docker daemon without if you
need to retain that functionality and want to to use this.
For more info:
https://docs.docker.com/engine/reference/commandline/dockerd/#run-multiple-daemons

❯ docker build -t follow -t follow:latest .
❯ xhost local:root
❯ docker run -it --rm --userns host --network host follow:latest

Dockerfile/.dockerignore for building and running a dev env (works
with X11.) There certainly probably are better ways to to export
a uid/gid to the container than to map the host ids, but it seems
to be the most intuitive given that xhost is required to allow
the container application to connect to X11; in the case of userns
host it will be container uid 0 -> uid 0 host but feel free to use
this at your own discretion to say the least it will help some
people who don't have a node/npm that's worth messing with installed
on their local machine to use this as well.

update to Dockerfile, use non-root user for operation in userns host mode

fix chown to use /home/iohzrd

fix data persistence volume and homedir/path/permission issue to agree with electron

[ghost]

remove the --rm flag and you will get volume persistence for the volume that is created and mounted to /home/iohzrd/persistent (also the $HOME is set to this, and the home which sits underneath persistent contains the electron project.) you can actually mount any supported volume to this path that you want, including named volumes using the -v param to docker run and there is also this which I have tried before and to some extent it works: https://hub.docker.com/r/ipfs/go-ipfs/ however this was not intended, and it's not really the best example of what you can do with IPFS either.

There's also KBFS:

• https://github.com/waldner/keybase-kbfs-docker
• https://github.com/keybase/client/tree/master/go/kbfs

I don't think I would really use that either. I think the best thing would be to create a keyring format that contains the user's config/pins and keys used to disseminate an identity that can be migrated between one instance of the application and another (self hosted vs hosted) and vice versa. The keyring would be itself encrypted / decrypted on the client side but also storable server side. I think this could fit the scheme of KBFS but you'll have to do a little research. Personally, I'd prefer an option in which I'm responsible for my own keyring so that if I wanted to use a hosted instance of the electron app I could and I could continue to use it suddenly without the hosted service by hosting my own as long as I've maintained a copy of my keyring. I think that it would be interesting to explore the possibility of something like keybase/KBFS but in general I would prefer to keep up with my own.

The idea of self hosted and decentralized everything is a good one, it should be that way, but in practice it's very difficult in terms of getting people to use it so having a middle ground is key to making it useful. The problem is the people who will not want to run self hosted are mostly your audience, in my experience they're lazy but I want their feedback anyway.

Your docs also mention a redesign of the comments system for that matter and I'm curious if that by any chance includes moderation, comment author signatures and comment attestation (approval / revocation?) That might be cool if its doable..