Migrate to TypeScript and PNPM

.dockerignore

@@ -0,0 +1 @@
+node_modules

.eslintrc.json

@@ -1,18 +1,17 @@
 {
- "env": {
- "browser": true,
- "es6": true,
- "node": true
- },
- "extends": "eslint:recommended",
- "globals": {
- "Atomics": "readonly",
- "SharedArrayBuffer": "readonly"
- },
- "parserOptions": {
- "ecmaVersion": 2018,
- "sourceType": "module"
- },
- "rules": {
- }
-}
+ "env": {
+ "browser": true,
+ "es6": true,
+ "node": true
+ },
+ "extends": "eslint:recommended",
+ "globals": {
+ "Atomics": "readonly",
+ "SharedArrayBuffer": "readonly"
+ },
+ "parserOptions": {
+ "ecmaVersion": 2018,
+ "sourceType": "module"
+ },
+ "rules": {}
+}

.gitignore

@@ -2,9 +2,10 @@
 
 # gathio custom
 
-config/api.js
-config/database.js
-config/domain.js
+dist
+src/config/api.js
+src/config/database.js
+src/config/domain.js
 public/events/*
 !public/events/.gitkeep
 

.nvmrc

@@ -1 +1 @@
-v16
+v18

.prettierignore

@@ -0,0 +1,4 @@
+dist
+public
+views
+pnpm-lock.yaml

.prettierrc.json

@@ -0,0 +1 @@
+{}

.travis.yml

@@ -2,7 +2,7 @@ language: shell
 os: linux
 
 services:
-  - docker
+ - docker
 
 script:
-  - ./test.sh
+ - ./test.sh

Dockerfile

@@ -1,8 +1,10 @@
-FROM node:16-alpine
+FROM node:18-alpine
 WORKDIR /app
 RUN apk add --no-cache python3 build-base
-ADD package.json package-lock.json /app/
-RUN npm install
+ADD package.json pnpm-lock.yaml /app/
+RUN npm install -g pnpm
+RUN pnpm install
 COPY . /app/
-RUN cp config/api-example.js config/api.js && cp config/domain-example.js config/domain.js && cp config/database-docker.js config/database.js
-CMD npm start
+RUN cp src/config/api-example.js src/config/api.js && cp src/config/domain-example.js src/config/domain.js && cp src/config/database-docker.js src/config/database.js
+CMD pnpm run build
+CMD pnpm run start

FEDERATION.md

@@ -6,18 +6,18 @@ This document is meant to be a reference for all the ActivityPub federation-rela
 
 To keep things simple, sometimes you will see things formatted like `Create/Note` or `Delete/Event` or `Undo/Follow`. The thing before the slash is the Activity, and the thing after the slash is the Object inside the Activity, in an `object` property. So these are to be read as follows:
 
-* `Create/Note`: a `Create` activity containing a `Note` in the `object` field 
-* `Delete/Event`: a `Delete` activity containing an `Event` in the `object` field
-* `Undo/Follow`: an `Undo` activity containing a `Follow` in the `object` field
+- `Create/Note`: a `Create` activity containing a `Note` in the `object` field
+- `Delete/Event`: a `Delete` activity containing an `Event` in the `object` field
+- `Undo/Follow`: an `Undo` activity containing a `Follow` in the `object` field
 
 When the word "broadcast" is used in this document, it means to send an Activity to individual inbox of each of the followers of a given Actor.
 
 This document has four main sections:
 
-* __Federation philosophy__ lays out the general model of how this is intended to federate
-* __General Actor information__ contains the basics of what to expect from our `Actor` objects
-* __Inbox behavior__ lists every incoming ActivityPub activity that the server recognizes, and tells you what it does in response to that activity, including any other ActivityPub activities it sends back out.
-* __Activities triggered from the web app__ tells you what circumstances on the web application cause the server to emit ActivityPub activities. (For example, when an event is updated via the web application, it lets all the ActivityPub followers know that the event has been updated.)
+- **Federation philosophy** lays out the general model of how this is intended to federate
+- **General Actor information** contains the basics of what to expect from our `Actor` objects
+- **Inbox behavior** lists every incoming ActivityPub activity that the server recognizes, and tells you what it does in response to that activity, including any other ActivityPub activities it sends back out.
+- **Activities triggered from the web app** tells you what circumstances on the web application cause the server to emit ActivityPub activities. (For example, when an event is updated via the web application, it lets all the ActivityPub followers know that the event has been updated.)
 
 Please note: there is an unfortunate collision between the English language and the ActivityPub spec that can make this document confusing. When this document uses the word 'event' with a lowercase-e and not in monospace, it refers to the thing that is being tracked in gathio: events that are being organized. When this document uses the word `Event` with a capital E and in monospace, it refers to the [`Event` object defined in the ActivityStreams Vocabulary spec](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-event).
 
@@ -37,7 +37,7 @@ Every event has an Actor. The Actor looks like this:
 
 ```json
 {
- "@context":[
+ "@context": [
  "https://www.w3.org/ns/activitystreams",
  "https://w3id.org/security/v1"
  ],
@@ -50,12 +50,12 @@ Every event has an Actor. The Actor looks like this:
  "summary": "<p><p>DESCRIPTION</p>\n</p><p>Location: LOCATION.</p><p>Starting DATETIME (human readable).</p>",
  "name": "EVENTNAME",
  "featured": "https://DOMAIN/EVENTID/featured",
- "publicKey":{
+ "publicKey": {
  "id": "https://DOMAIN/EVENTID#main-key",
  "owner": "https://DOMAIN/EVENTID",
  "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nOURPUBLICKEY\n-----END PUBLIC KEY-----\n"
  },
- "icon":{
+ "icon": {
  "type": "Image",
  "mediaType": "image/jpg",
  "url": "https://DOMAIN/events/EVENTID.jpg"
@@ -85,7 +85,7 @@ When the server receives a `Follow` Activity, it grabs the `actor` property on t
 
 Assuming we can find the Actor object, then we emit an `Accept` Activity back to the server, containing the full `Follow` that we just parsed. This lets the other server know that we have fully processed the follow request.
 
-After this, we *also* send a `Create` Activity to the actor's inbox, containing an `Event` object with the information for this event. This is, at the moment, future compatibility for servers that consume `Event` objects. This is sent as a "direct message", directly to the inbox with no `cc` field and not addressing the public timeline.
+After this, we _also_ send a `Create` Activity to the actor's inbox, containing an `Event` object with the information for this event. This is, at the moment, future compatibility for servers that consume `Event` objects. This is sent as a "direct message", directly to the inbox with no `cc` field and not addressing the public timeline.
 
 And finally we send the user a `Create` Activity containing a `Question` object. The `Question` is an invitation to RSVP to the event. Mastodon renders this as a poll to the user, which lets them send back to us a "Yes" RSVP directly from their client UI should they so choose. This is also sent as a "direct message". Some clients like Friendica, simply ignore `Question` objects, which is fine since the user can use built-in RSVP function of Friendica to RSVP anyway (see below).
 
@@ -102,13 +102,13 @@ The plan is to have this support two ways to RSVP:
 1. The user answers the `Question` sent out to the prospective attendee in the form of a `Create/Note` in the style of Mastodon polls. This is mostly a hack for implementations like Mastodon that don't have vocabulary built in to RSVP to `Event`s.
 2. The user sends a `Accept/Event` or `Undo/Accept/Event` back to our server. This is for implementations like Friendica that support `Event` and do things like automatically render incoming events in their UI with an RSVP interface. We currently don't accept `Reject/Event` or `TentativeAccept/Event` because gathio has no concept of a "Maybe" or "No" RSVP. It probably should have that in the future, at which case we could meaningfully parse this stuff.
 
-__The `Question` method__
+**The `Question` method**
 
 If the inbox gets a `Create/Note`, there is a chance that this is a response to a `Question` that we sent a user. So the first thing we do is check its `inReplyTo` property. If it matches the id of a `Question` we sent this user, and this user is still following us, then we fetch the user's profile info. This is to make sure we have their newest `preferredUsername` in their `Actor` object (falling back to `name` and then `actor`), which we will honor as the name we display on the RSVP. We then add this person to our database as an attendee of the event.
 
 Next we confirm that the user has RSVPed. We do this by sending them a `Create/Note` via direct message. The note tells them they RSVPed, and gives them a URL they can click on to instantly un-RSVP if they need to.
 
-__The `Accept/Event` method__
+**The `Accept/Event` method**
 
 If the inbox gets an `Accept/Event`, then it assumes this is an affirmative RSVP from the actor who sent it. We check to see if the `id` of the `Event` matches the `id` of an `Event` that we sent ot this actor. If it does, then it must be a valid, affirmative RSVP. We then get the `preferredUsername` or `name` from the actor object, and add that actor to the database as an attendee. TODO: support either object URI or embedded object here.
 
@@ -126,7 +126,7 @@ Since a user can comment on the event via ActivityPub, they should be able to de
 
 ### Incoming private messages
 
-*TODO*: If someone tries to DM the event, we need to reply with a message like "Sorry, this service only supports posting public messages to the event page. Try contacting the event organizer directly if you need to have a private conversation."
+_TODO_: If someone tries to DM the event, we need to reply with a message like "Sorry, this service only supports posting public messages to the event page. Try contacting the event organizer directly if you need to have a private conversation."
 
 ## Activities triggered from the web app
 
@@ -144,7 +144,7 @@ And finally we send an `Update/Event` out with the new event details in the `Eve
 
 ### Delete event
 
-When an event is deleted by its administrator, or the event has been deleted due to it being one week after the event has ended, we send a `Delete/Actor` out to followers.  This lets followers know that the event has been deleted, and their server should remove its profile from their database. (On Mastodon this results in an automatic "unfollow", which is good because we want people's follow counts to go back to normal after an event is over and has been deleted.)
+When an event is deleted by its administrator, or the event has been deleted due to it being one week after the event has ended, we send a `Delete/Actor` out to followers. This lets followers know that the event has been deleted, and their server should remove its profile from their database. (On Mastodon this results in an automatic "unfollow", which is good because we want people's follow counts to go back to normal after an event is over and has been deleted.)
 
 We also send a `Delete/Event` out to followers. For an application like Friendica, this removes the event from the calendar of a follower.