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-keygenand then do this:
git clone d@cryptonomic.net:public_git/sami.gitThis 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.
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 d@cryptonomic.net:./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.)
The same server is providing some other services too; for example, it has a dynamic dns service that provides self-authenticating names.
Try this:
ssh dyndns@cryptonomic.netand 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:~$ dyndns.ssh-rsa.cryptonomic.net -4
5f79049e88ade4##########################.ssh-rsa.cryptonomic.net 66.##.##.###
Connection to cryptonomic.net closed.
d@fifty:~$ dyndns.ecdsa-sha2-nistp256.cryptonomic.net -6
7ed880b2a6eedd##########################.ecdsa-sha2-nistp256.cryptonomic.net 2601:###:####:####:###:####:####:###
Connection to cryptonomic.net 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 cryptonomic.net, but this is not yet functional. See https://en.wikipedia.org/wiki/SSHFP_record.
I also registered *.*.cryptonomic.net in the public suffix list, so that those subdomains can be used to create LetsEncrypt certificates using ACME. (See https://en.wikipedia.org/wiki/Public_Suffix_List, https://en.wikipedia.org/wiki/Let%27s_Encrypt.)
I mentioned to you before that I wrote an ACME client in Haskell (see https://git.cryptonomic.net/acme-certify.git/) 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.
Eventually I want to register *.cryptonomic.net in an RFC as special TLDs akin to .onion (see https://tools.ietf.org/html/rfc7686).
Subdomains of cryptonomic.net 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 https://git.cryptonomic.net/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.