diff --git a/ansible/playbook.yml b/ansible/playbook.yml deleted file mode 100644 index 59c2c8ea..00000000 --- a/ansible/playbook.yml +++ /dev/null @@ -1,30 +0,0 @@ ---- -- name: Update Ditto - hosts: all - become: true - tasks: - - name: Update Deno - shell: - cmd: curl -fsSL https://deno.land/x/install/install.sh | sh - environment: - DENO_INSTALL: /usr/local - become_user: root - - - name: Update Soapbox - shell: - cmd: deno task soapbox - chdir: /opt/ditto - become_user: ditto - - - name: Update ditto from the main branch - git: - repo: 'https://gitlab.com/soapbox-pub/ditto.git' - dest: '/opt/ditto' - version: main - become_user: ditto - - - name: Restart ditto service - systemd: - name: ditto - state: restarted - become_user: root diff --git a/docs/auth.md b/docs/auth.md deleted file mode 100644 index 119a7dc2..00000000 --- a/docs/auth.md +++ /dev/null @@ -1,23 +0,0 @@ -# Authentication in Ditto - -One of the main benefits of Nostr is that users control their keys. Instead of a username and password, the user has a public key (`npub` or `pubkey`) and private key (`nsec`). The public key is a globally-unique identifier for the user, and the private key can be used to sign events, producing a signature that only the pubkey could have produced. - -With keys, users have full control over their identity. They can move between servers freely, and post to multiple servers at once. But with such power comes great responsibilities. Users cannot lose control of their key, or they'll lose control over their account forever. - -## Managing Keys - -There are several ways to manage keys in Nostr, and they all come with trade-offs. It's new territory, and people are still coming up with new ideas. - -The main concerns are how to **conveniently log in on multiple devices**, and **who/what to trust with your key.** - -### Current Solutions - -1. **Private key text.** Users copy their key between devices/apps, giving apps full control over their key. Users might email the key to themselves, or better yet use a password manager, or apps might even provide a QR code for other apps to scan. This method is convenient, but it's not secure. Keys can get compromised in transit, or by a malicious or vulnerable app. - -2. **Browser extension.** For web clients, an extension can expose `getPublicKey` and `signEvent` functions to web-pages without exposing the private key directly. This option is secure, but it only works well for laptop/desktop devices. On mobile, only FireFox can do it, with no support from Safari or Chrome. It also offers no way to share a key across devices on its own. - -3. **Remote signer**. Users can run a remote signer program and then connect apps to it. The signer should be running 24/7, so it's best suited for running on a server. This idea has evolved into the creation of "bunker" services. Bunkers allow users to have a traditional username and password and login from anywhere. This method solves a lot of problems, but it also creates some problems. Users have to create an account on a separate website before they can log into your website. This makes it an option for more advanced users. Also, it's concerning that the administrator of the bunker server has full control over your keys. None of this is a problem if you run your own remote signer, but it's not a mainstream option. - -4. **Custodial**. Apps which make you log you in with a username/password, and then keep Nostr keys for each user in their database. You might not even be able to export your keys. This option may be easier for users at first, but it puts a whole lot of liability on the server, since leaks can cause permanent damage. It also gives up a lot of the benefits of Nostr. - -Each of these ideas could be improved upon greatly with new experiments and technical progress. But to Ditto, user freedom matters the most, so we're focusing on non-custodial solution. Even though there are security risks to copying around keys, the onus is on the user. The user may fall victim to a targeted attack (or make a stupid mistake), whereas custodial servers have the ability to wipe out entire demographics of users at once. Therefore we believe that custodial solutions are actually _less_ secure than users copying around keys. Users must take precautions about which apps to trust with their private key until we improve upon the area to make it more secure (likely with better support of browser extensions, OS key management, and more). diff --git a/docs/debugging.md b/docs/debugging.md deleted file mode 100644 index 879f36cd..00000000 --- a/docs/debugging.md +++ /dev/null @@ -1,27 +0,0 @@ -# Debugging Ditto - -Running the command `deno task debug` will start the Ditto server in debug mode, making it possible to inspect with Chromium-based browsers by visiting `chrome://inspect`. - -From there, go to the "Performance" tab and click "Start profiling". Perform the actions you want to profile, then click "Stop profiling". You can then inspect the call stack and see where the time is being spent. - -## Remote debugging - -If the Ditto server is on a separate machine, you will first need to put it into debug mode. Edit its systemd file (usually located at `/etc/systemd/system/ditto.service`) and change `deno task start` to `deno task debug` in the `ExecStart` line. Then run `systemctl daemon-reload` and `systemctl restart ditto`. - -To access the debugger remotely, you can use SSH port forwarding. Run this command on your local machine, replacing `@` with the SSH login for the remote machine: - -```sh -ssh -L 9229:localhost:9229 @ -``` - -Then, in Chromium, go to `chrome://inspect` and the Ditto server should be available. - -## SQL performance - -To track slow queries, first set `DEBUG=ditto:sql` in the environment so only SQL logs are shown. - -Then, grep for any logs above 0.001s: - -```sh -journalctl -fu ditto | grep -v '(0.00s)' -``` diff --git a/docs/installation.md b/docs/installation.md deleted file mode 100644 index 9077a7cb..00000000 --- a/docs/installation.md +++ /dev/null @@ -1,15 +0,0 @@ -# Installing Ditto - -First, install Deno: - -```sh -curl -fsSL https://deno.land/x/install/install.sh | sudo DENO_INSTALL=/usr/local sh -``` - -Now, run Ditto: - -```sh -deno run -A https://gitlab.com/soapbox-pub/ditto/-/raw/main/src/server.ts -``` - -That's it! Ditto is now running on your machine. diff --git a/docs/mastodon-api.md b/docs/mastodon-api.md deleted file mode 100644 index 48684b6f..00000000 --- a/docs/mastodon-api.md +++ /dev/null @@ -1,9 +0,0 @@ -# Mastodon API - -Ditto implements Mastodon's client-server API, a REST API used by Mastodon mobile apps and frontends to interact with Mastodon servers. While it was originally designed for Mastodon, it has been adopted by other ActivityPub servers such as Pleroma, Mitra, Friendica, and many others. - -Note that Mastodon API is **not** ActivityPub. It is not the API used to federate between servers. Instead, it enables user interfaces, mobile apps, bots, and other clients to interact with Mastodon servers. - -Mastodon is built in Ruby on Rails, and its API is inspired by Twitter's legacy REST API. Rails, being an MVC framework, has "models", which it maps directly to "Entities" in its API. - -Endpoints return either a single Entity, or an array of Entities. Entities Entities are JSON objects with a specific structure, and are documented in the [Mastodon API documentation](https://docs.joinmastodon.org/api/).