don
I was interested by mastodon, but found it to be a little too heavyweight for me. I want something I can run as a single binary with no other services. To that end, I'm embarking on writing this - tentatively named don.
I'm not sure what it'll end up being. Right now it's just an experiment in
plugging different protocols together a rudimentary read-only client. Maybe
it'll be a full node implementation, but maybe not.
Beware!
I'm changing lots of things really often right now. I can't guarantee that you'll be able to upgrade from one version to the next without a lot of manual intervention at the moment. Once I've got some of the schemas and APIs nailed down, I'll enact a stability policy. Until then, I'll try to keep the really bad breaking changes to a minimum, and I'll try to batch them up whenever I can.
Prebuilt Binaries
You can download a binary from bintray.
On linux and macos you'll have to chmod +x the file after you download it.
Keep in mind that this is a terminal program, so if you double-click it or try
to open it from your downloads, you won't really see much happen. You'll need
to open a terminal (Terminal.app on macos, cmd.exe on Windows, xterm or
similar on linux), browse to the location of the binary, and run it like so:
$ ./don_dev_darwin-amd64 --public_url https://my-domain-name.com/
Change the filename and public_url argument to suit. Be sure to check out
the help output (via --help) to see the available options.
Usage
usage: don --public_url=PUBLIC_URL [<flags>]
Really really small OStatus node.
Flags:
--help Show context-sensitive help (also try --help-long and --help-man).
--addr=":5000" Address to listen on.
--database="don.db" Where to put the SQLite database.
--public_url=PUBLIC_URL URL to use for callbacks etc.
--log_level=INFO How much to log.
--pubsub_refresh_interval=15m PubSub subscription refresh interval.
--record_documents Record all XML documents for debugging.
All these options are available as environment variables as well - just make
them uppercase, e.g. addr is ADDR.
Build Portable Binary
Right now, you'll need the following:
$ go get fknsrs.biz/p/don
$ cd $GOPATH/src/fknsrs.biz/p/don
$ make
You should see something like the following:
cd client && yarn run build-server
yarn run v0.16.1
$ NODE_ENV=production webpack -p --bail --config webpack.config.server.js
[long output omitted]
cd client && yarn run build-client
yarn run v0.16.1
$ NODE_ENV=production webpack -p --bail --config webpack.config.client.js
[long output omitted]
go build -ldflags=-s -o don
rice append --exec don
At the end, you'll have a self-contained binary named don that you can move
anywhere you like.
Build Cross-Platform Binaries
This is the same as above, except that you'll need one more tool:
Now, instead of running make, you run make cross. You'll end up with
binaries named don-darwin-10.6-amd64, don-linux-amd64, don-linux-arm-5,
and don-windows-4.0-amd64.exe.
Development
Most of the work will probably be in the client code. To make this easier,
there's a live_reload makefile target. This runs a couple of webpack
processes, and the don server, wiring the server up so that it uses the hot
reloading bits of webpack. If none of that made sense, don't worry. I've tried
to paper over all the details on purpose - configuring webpack is not for
the faint of heart.
All you need to know is that when you run the live reloading environment, you have to provide all your server parameters as environment variables. I suggest something like the following:
$ export PUBLIC_URL=http://my-host.com
$ export LOG_LEVEL=DEBUG
$ make live_reload
Once it's all running, you should be able to open http://127.0.0.1:5100/ in
your browser. You'll see a very quick flash of unstyled content, but then
the client JS should kick in and fix it up.
When this is running, you'll be able to save files and have the content in the browser update automatically. This makes working on client stuff much nicer.
Code Formatting
The main idea for the code formatting in this project is that it should be automated. Not just automatically checked, but automatically applied. No bikeshedding, no suggestions, no discussions. Computer is always right.
For go, use gofmt.
For JavaScript, use prettier with
--single-quote and --trailing-comma es5.
For CSS, use csscomb with the config provided in
client/.csscomb.json.
For shell scripts, use shfmt with -i 2.
Code Analysis
There are a couple of tools in use right now to do some static analysis on the application's code. I expect that this list will grow in time.
ESLint is a linter, and in this case it's used to catch
some basic logic errors. It is not used for detecting problems with or
enforcing a formatting style. That is handled by prettier in the "Code
Formatting" section.
Flow is a static analysis and gradual type engine for JavaScript. I'm not aiming for 100% coverage with Flow - I'm just using it to help catch really obvious bugs (e.g. accessing properties on null/undefined).
flow-report (in client/flow-report.js) is used to make an HTML report (in
client/coverage/flow) from the coverage data Flow can produce.
Acknowledgements
Some included icons were made by Freepik at Flaticon, which were shared under the CC 3.0 BY Creative Commons license.
The included username blacklist is based on The Big Username Blacklist by Martin Sandström, which was provided under the MIT license.
Some code for serialising forms was adapted from freiform by Falk Hoppe, which was provided under the Apache License 2.0.