Git hosting services on

This is a self-hosted minimalist alternative to using github, gitlab, etc. This page explains by example how to use those features:

Go ahead and try this out. Run ssh-keygen if you don't have an ssh key in $HOME/.ssh/:

[ -e "~/.ssh/id_rsa" ] || ssh-keygen

and then do this:

git clone

This creates a clone that you can push back into. Notice: you did not need to create an account, or upload your keys to the server, or get any preauthorization from me to push into the repo. But your changes don't go live; they're put into a separate "git namespace" named after your public key.

Public rsync on

This is just a way to send me a file and to prove your identity as you do it (again without having to register an account or sign in on a web page or anything).

To send me a file just do this:

rsync -aP the-file

Simiarly, I can share files over rsync by putting them into my ~/public_rsync directory. It's like public_ftp or public_html except it works over ssh server, so that ssh host keys can provide identity security without a trusted third party. (And rsync makes it easy to share entire directory hierarchies and to keep them synced, so it's much better than http or ftp.)

Dynamic DNS services on

The same server is providing some other services too; for example, it has a dynamic dns service that provides self-authenticating names.

Try this:


and the output will tell you the DNS record that was created. You can use it to connect back to your machine, if your machine has IP connectivity.

There is also a convenience script that selects the local system's ssh host key as the key (instead of using your user's client key):

d@fifty:~$  -4 66.##.##.###
Connection to closed.

d@fifty:~$ -6 2601:###:####:####:###:####:####:###
Connection to closed.

(Output modified with `####` for privacy.)

That script is here:

The generated name can in principle be "self-authenticating" when used to connect via ssh. Currently there is no client-side implementation that checks this, but it wouldn't be hard.

I will also be providing SSHFP records on, but this is not yet functional. See

The Public Suffix List (PSL)

I also registered *.* in the public suffix list, so that those subdomains can be used to create LetsEncrypt certificates using ACME. (See,

I mentioned to you before that I wrote an ACME client in Haskell (see and (although I haven't worked on this in a while) my plan was to integrate the ACME client with the ssh-based cryptonomic DNS service and a web server, so that a single binary can run and provide a web server with an https:// URL, without having to register any domain or set anything up with any third party.

The peer-to-peer (P2P) future: eliminating

Eventually I want to register * in an RFC as special TLDs akin to .onion (see

Subdomains of would be resolved locally using a p2p service providing a dns server. The SSHFP records could also be generated locally. This would leave no possibility for any third party (such as ICANN) to break connectivity using the DNS.

The dht-client.git project, which provides access to the uTox and bittorrent DHTs (distributed hash table provided by a p2p network, originally created to replace centralized bittorrent trackers), is supposed to provide this feature using those DHT p2p networks. Currently, dht-client only uses the DHT to provide a jabber based chat, compatible with uTox.