Why Mastodon

As part of my self-hosting journey, I shut down essentially all my social media in 2019 with the exception of my LinkedIn, Spotify, and a twitter account which I used to follow but not to post. I didn’t think it was possible to really self-host social media, but the events of the past two months and the explosive growth that Mastodon has undergone has changed that. Regardless of what you think about the recent changes at Twitter and the rise of Mastdon in headlines, the idea of decentralized and self-hostable social media is super interesting, and totally feasible.

As always it’s important to approach self-hosting with eyes wide open, and there are definitely pros and cons compared to the big-tech versions of social media:

Setting up an Instance

Mastodon is one of several software platforms that communicate with each other through the ActivityPub protocol. Any platform that uses ActivityPub can technically talk to each other, though some are more specialized around how closely they resemble walled garden services. Mastodon and Pleroma are two that closely resemble Twitter, and others like Pixelfed are more similar to Instagram. Any platform which can use the ActivityPub protocol, can be classified as “part of the fediverse”.

I initially tried out Plermoa due to ease of setup (it requires far less resources and work to get running), but ultimately decided to go for a full Mastodon setup. Lucky for me (any anyone who wants to set up Mastodon) the always incredible folks over at linuxserver.io recently released a single docker image which packages up all the services needed to stand up Mastodon yourself except for redis and postgres.

Because social media is inherently “social” I set up a new VPS and used a new domain for my Mastodon instance rather than the domain/VPS I use for my personal services. The docker compose file can be found here. Here’s the relevant section for mastodon, the other key services (postgres and redis) are standard installs, check out the full docker compose to see the entire setup file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

  mastodon:
    container_name: mastodon
    image: linuxserver/mastodon:latest
    restart: always
    networks:
      - traefik
      - internal
    depends_on:
      - traefik
      - postgres
      - redis
    ports:
      - 8002:80/tcp
      - 8443:443/tcp
    volumes:
      - $DOCKERDIR/mastodon:/config
    security_opt:
      - no-new-privileges:true
    environment:
      - TZ=$TZ
      - PUID=$PUID
      - PGID=$PGID
      - LOCAL_DOMAIN=$MAST_DOMAIN
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - DB_HOST=postgres
      - DB_USER=mastodon
      - DB_NAME=mastodon
      - DB_PASS=$MAST_POSTGRES_PASSWORD
      - DB_PORT=5432
      - ES_ENABLED=false
      - SECRET_KEY_BASE=$SECRET_KEY_BASE
      - OTP_SECRET=$OTP_SECRET
      - VAPID_PRIVATE_KEY=$VAPID_PRIVATE_KEY
      - VAPID_PUBLIC_KEY=$VAPID_PUBLIC_KEY
      - SMTP_SERVER=$SMTP_HOST
      - SMTP_PORT=$SMTP_PORT
      - SMTP_LOGIN=$SMTP_USERNAME
      - SMTP_PASSWORD=$SMTP_PASSWORD
      - SMTP_FROM_ADDRESS=$SMTP_FROM
      - S3_ENABLED=true
      - S3_ENDPOINT=$S3_ENDPOINT
      - S3_HOSTNAME=$S3_HOSTNAME
      - S3_BUCKET=$S3_BUCKET
      - AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      - AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      - S3_ALIAS_HOST=$S3_ALIAS_HOST
      #- WEB_DOMAIN=$MAST_DOMAIN #optional
      #- RAILS_SERVE_STATIC_FILES=true
      #- ES_HOST=es #optional
      #- ES_PORT=9200 #optional
      #- ES_USER=elastic #optional
      #- ES_PASS=elastic #optional
    labels:
      - "traefik.enable=true"
      ## HTTP Routers
      - "traefik.http.routers.mastodon-rtr.entrypoints=https"
      - "traefik.http.routers.mastodon-rtr.rule=Host(`$MAST_DOMAIN`)"
      - "traefik.http.routers.mastodon-rtr.tls=true"
      ## Middlewares
      - "traefik.http.routers.mastodon-rtr.middlewares=chain-no-auth@file"
      ## HTTP Services
      - "traefik.http.routers.mastodon-rtr.service=mastodon-svc"
      - "traefik.http.services.mastodon-svc.loadbalancer.server.port=443"
      - "traefik.http.services.mastodon-svc.loadbalancer.server.scheme=https"
      - "traefik.http.services.mastodon-svc.loadbalancer.serversTransport=masto@file"

There are a few quirks to be aware of with the linuxserver.io image:

• Some services are optional such as using an S3 bucket for media hosting (I highly recommend) and implementing ElasticSearch (probably not necessary, especially for a small instance)
• Mastodon includes an internal forced 301 redirect to https, and then proxies to port 443, but it does this with a self-signed certificate. This can create challenges if you’re putting the Mastodon service behind another reverse proxy like nginx, or in my case Traefik.
  • I’m actually still working with this one, but in the near term if you set your instance up to skip the internal verification of the certificate, you’ll be set. All externally facing traffic will be secure, but some of the traffic inside of the container won’t necessarily be. More discussion on this here

Media Storage

Social Media can generate a surprising amount of media, very quickly. Even on my single-user instance I’ve amassed around 12Gb of media, only a month in. One option would be to just let your server handle all the media, but that can eat up a lot of storage space, and generate high costs depending on your plan and allocated bandwidth. Backblaze put together a fantastic guide which outlines setting up cloudflare as a caching layer in front of backblaze to bring your bandwidth costs to essentially 0, with very low storage costs and high availability of your media, all hosted under your own domain name.

Accessing Twitter

Not all Twitter users will move to Mastodon, and there are a few ways to follow their accounts. My goal here was to have a single location to access my content, have it free of ads, and ideally to be stored on my server.

Nitter

• Nitter is essentially an mirror of content from Twitter. I haven’t personally used it, but it seems like a very simple way to access both Twitter content without actually using Twitter. Unfortunatley I don’t see any way to bring Nitter + Mastodon into one seamless activity feed, so I explored other options.

BirdsiteLive

• This is what I ended up going with. BirdsiteLive is a bridge between the Twitter API and the ActivityPub protocol. It essentially allows you to follow any twitter account on Mastodon, just by looking up the twitter username and using the BirdsiteLive domain you set up as the “instance”.

Here’s the BirdsiteLive portion of my docker-compose file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

  bsl:
    container_name: birdsitelive
    image: nicolasconstant/birdsitelive:latest
    restart: unless-stopped
    networks:
      - traefik
      - internal
    depends_on:
      - traefik
      - postgres
    security_opt:
      - no-new-privileges:true
    ports:
      - "8009:80"
    environment:
      - TZ=$TZ
      - PUID=$PUID
      - PGID=$PGID
      - Instance:Domain=bsl.$DOMAINNAME
      - Instance:AdminEmail=name@domain.ext
      - Instance:ResolveMentionsInProfiles=true
      - Db:Type=postgres
      - Db:Host=postgres
      - Db:Name=birdsitelive
      - Db:User=$BSL_POSTGRES_USER
      - Db:Password=$BSL_POSTGRES_PASSWORD
      - Twitter:ConsumerKey=$BSL_TWITTER_API_KEY
      - Twitter:ConsumerSecret=$BSL_TWITTER_API_SECRET
      - Moderation:FollowersWhiteListing=$MAST_DOMAIN
      - Instance:Name=$BSL_NAME
    labels:
      - "traefik.enable=true"
      ## HTTP Routers
      - "traefik.http.routers.bsl-rtr.entrypoints=https"
      - "traefik.http.routers.bsl-rtr.rule=Host(`bsl.$DOMAINNAME`)"
      - "traefik.http.routers.bsl-rtr.tls=true"
      ## Middlewares
      - "traefik.http.routers.bsl-rtr.middlewares=chain-no-auth@file"
      - "traefik.http.routers.bsl-rtr.middlewares=middlewares-bsl@file"
      ## HTTP Services
      - "traefik.http.routers.bsl-rtr.service=bsl-svc"
      - "traefik.http.services.bsl-svc.loadbalancer.server.port=80"

There is still a fair amount to be desired with this, and it requires a special API from Twitter which needs to be “approved” (it appears that Twitter has automated this approval, and my API account request was granted immediately after I filled out the form requesting it). The API also has limits which you can see on your BirdsiteLive page on whatever domain you host it on, so you’ll want to only allow instances / users to access and follow accounts (configured in the compose file).

I’d like to replace this with Nitter at some point, if there is a good solution to convert a Nitter feed into an ActivityPub feed.

Mobile Apps

I only used twitter on my phone, so the mobile experience is pretty important. I’m an iOS user, and after evaluating a few different apps, I found two which are fantastic:

1. Free Mastoot: This app is fairly mature, and has all the features I would want in a Mastodon app. It isn’t open source, but it checks pretty much every other box.
2. Paid Ivory: For those who are used to Tweetbot, this will feel like home. Tapbots are working to implement a Mastodon version of Tweetbot, called Ivory. This is currently in alpha testing, so if you want to hop on the train you’ll need to get in on their TestFlight list. They’ve been posting TestFlight openings to the Ivory Mastodon account. The alpha/beta isn’t paid, but I’m sure that like Tweetbot the final product will be.

Get Posting

Yes Posting - I’m glad that the “toot” went the way of the actual Mastodon, it needed to happen for anyone to take the service seriously.

If you have any thoughts, different experiences, or want to correct anything above, hit me up on Mastodon!

Docker enables containers to quickly be spun up and used anywhere, but one of the risks many self-hosters take is exposing sensitive services to the open web. There is a balance between safety and convenience with each application exposed, but there are some applications which have no need to be publicly accessible.

These typically include administrative applications such as:

• Portainer
• PGAdmin (Postgres)
• phpMyAdmin (Mariadb)
• Redis Commander
• Any other service you don’t want exposed

One way to keep these services running but prevent them from being exposed is to place them behind a secure VPN. There are just a handful of major VPN protocols out there today, OpenVPN, IPSec, and the new Wireguard protocol are the big names. While Wireguard is new on the block and may not have had the level of auditing that OpenVPN has, it is blazing fast, and apparently so elegantly written that the creator of Linux, Linus Torvolds, called it a work of art before including it directly in the Linux Kernel.

Some may want to hide all their applications behind a VPN for very high security, while others like may only want to hide the ones which are rarely needed. This guide outlines how to configure specific services to only be accessible from behind your VPN while leaving others publicly accessible.

Set up a local docker-compose network

Add a new network to docker-compose for your services to live on/

1
2
3
4

networks:
  vpn-subnet:
    external:
      name: vpn-subnet

Setting up Wireguard

Although Wireguard doesn’t maintain a docker container, the excellent folks at linuxserver.io do. Setting up a wireguard container in Docker is as simple as adding a new service to your docker-compose file. This docker-compose snippet assumes you have a few environment variables configured:

• DOCKERDIR set to the directory you want your services to store their non-temporary data files in. For this example we assume it is ~/docker/
• DOMAINNAME set to the domain you’re hosting the content on.
• PUID set to the user id your docker runs under (run id yourdockerusername and find the numeric value associated with “uid”)
• PGID set to the group id your docker runs under (run id yourdockerusername and find the numeric value associated with “gid”)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

  wireguard:
    container_name: wireguard
    image: linuxserver/wireguard:latest
    restart: unless-stopped
    networks:
      vpn-subnet:
        ipv4_address: 20.20.10.5
    volumes:
      - $DOCKERDIR/wireguard:/config
      - /lib/modules:/lib/modules
    ports:
      - 51820:51820/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    security_opt:
      - no-new-privileges:true
    environment:
      - TZ=$TZ
      - PUID=$PUID
      - PGID=$PGID
      - SERVERURL=wireguard.$DOMAINNAME
      - SERVERPORT=51820
      - PEERS=2
      - PEERDNS=auto
      - INTERNAL_SUBNET=10.13.14.0

Most of the above should look pretty familiar if you’ve used docker-compose before, with the exception of the “sysctls” and “cap_add” sections. The “sysctls” section enables the wireguard container to manage ipv4 network connections, something we need for our internal VPN subnet. The “cap_add” section essentially grants some extra privileges to our container, such as the ability to control network functions, and manage kernel modules. We’re also mounting /lib/modules as a volume into the container.

I chose to set the container specific environment variable “PEERS” to 2, which means that the container will automatically generate two profiles for connections. I personally use one for my phone to connect on the go and one for my desktop. You’ll see the QR codes for these peers in the logs, and if you want to see one of the codes you can run sudo docker exec -it wireguard /app/show-peer 1.

Set up DNS, Firewall Passthrough, and Port Forwarding

If you aren’t using wildcard cname values for subdomains, you’ll need to manually add ‘wireguard’ as a new CNAME entry on your DNS manager. Note that this does open up the standard wireguard port of 51820 to the internet, so if you’re hosting at home you will need to forward whichever port you decide to use from your router to your server.

You’ll also need to allow access to the port via your firewall

1

sudo ufw allow 51820/udp 

Place Container Behind your New VPN

We need to assign static ip addresses on the network we created above. The YAML format for this can be a bit different, and you may need to specify “null” as the target for any existing networks assigned to the containers. In my case I have an “internal” network used for services such as my database containers as can be seen in the examples of some services I’ve placed behind my VPN below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

  pgadmin:
    container_name: pgadmin
    image: dpage/pgadmin4:latest
    restart: unless-stopped
    networks:
      internal: null
      vpn-subnet:
        ipv4_address: 20.20.10.3
    depends_on:
      - postgres
    security_opt:
      - no-new-privileges:true
    volumes:
      - $DOCKERDIR/pgadmin:/var/lib/pgadmin
    environment:
      - TZ=$TZ
      - PUID=$PUID
      - PGID=$PGID
      - PGADMIN_DEFAULT_EMAIL=$PERSONAL_EMAIL
      - PGADMIN_DEFAULT_PASSWORD=$PGADMIN_DEFAULT_PASSWORD
      - PGADMIN_LISTEN_PORT=5050

  pma:
    container_name: phpmyadmin
    image: phpmyadmin/phpmyadmin:latest
    container_name: phpmyadmin
    restart: unless-stopped
    networks:
      internal: null
      vpn-subnet:
        ipv4_address: 20.20.10.4
    depends_on:
      - mariadb
    secrets:
      - mysql_root_password
    environment:
      - TZ=$TZ
      - PUID=$PUID
      - PGID=$PGID
      - PMA_HOST=mariadb
      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql_root_password
      - ServerName=$DOMAINNAME

Assign Readable Domain Names

Technically your services are accessible from the IP addresses you’ve assigned, after you’ve connected to your VPN, but who is going to remember the IP address you assigned to each? To get around this and assign standard domain names, we can utilize the COREDNS setup running in the Wireguard container.

First create a wireguard directory in your docker apps directory. This assumes that you’re using your home directory as the docker apps directory

1

mkdir ~/docker/wireguard/coredns/ 

Now we’ll add the Corefile configuration it needs to manage local domain names.

1

nano ~/docker/wireguard/coredns/Corefile

The below is an example of what the Corefile looks like for the four applications I’ve configured. The first portion starting with “loop” effectively forwards DNS requests to the host DNS resolver. Replace the subdomains with the applications you want to host behind your VPN. Replace EXAMPLE.COM with your domain name, no CAPS needed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

. {
    loop
    forward . /etc/resolv.conf
}

portainer.EXAMPLE.COM:53 {
    file portainer.EXAMPLE.COM.db
    log
    errors
}

pma.EXAMPLE.COM:53 {
    file pma.EXAMPLE.COM.db
    log
    errors
}

pga.EXAMPLE.COM:53 {       
    file pga.EXAMPLE.COM.db
    log                  
    errors               
}                        

redis.EXAMPLE.COM:53 {
    file redis.EXAMPLE.COM.db
    log
    errors
}

Now we need to create the files referenced in the above Corefile, which hold the configuration details each service needs. Here’s an example for my portainer container, again replace EXAMPLE.COM with your domain name.

1

nano ~/docker/wireguard/coredns/portainer.EXAMPLE.COM.db

The contents should follow this structure, replacing EXAMPLE.COM with your domain name.

1
2
3
4
5
6
7
8

portainer.EXAMPLE.COM.        3600 IN SOA portainer.EXAMPLE.COM. YOURNAME.portainer.EXAMPLE.COM. (
                                2017042745 ; serial
                                7200       ; refresh (2 hours)
                                3600       ; retry (1 hour)
                                1209600    ; expire (2 weeks)
                                3600       ; minimum (1 hour)
                                )
portainer.EXAMPLE.COM.     IN A     20.20.10.2

The “serial” value can be set to any value, one suggestion would be the date you added the service. You should also replace the “YOURNAME” in the example above with an identifier. I personally use “epierce”. You’ll also want to modify the IP address on the last line of the file to be unique to that service, and to match the IP address you specified in your docker-compose file under vpn-subnet: ipv4_address: for that service.

Secure Your Files

These files are a little sensitive, so let’s lock them down to be root accessible only.

1
2

sudo chown root:root ~/docker/wireguard 
sudo chmod 600 ~/docker/wireguard

Testing Access

Your services are now available only when you connect to your VPN. Go ahead and connect and try accessing one of your services by going to the domain name you configured (ie pga.EXAMPLE.COM).

We aren’t actually going through a reverse proxy here, and there isn’t a service like Caddy, Traefik, or NGINX which manages port mapping. Services accessible over port 80 will work as normal, but services which need to be accessed on a non-standard port will need to have that port specified. For example portainer which I have configured to listen on port 9000, will need to be accessed by typing portainer.EXAMPLE.COM:9000 in your URL bar.

Now you should be able to access your services securely, while keeping your standard services accessible as normal.

I got my order in for the M1 Max, which is my first ARM64 based notebook, and started migrating over to it. As the first M1 based notebooks were released over a year ago, virtually all of the programs I want available have already been compiled to use the native M1 architecture, with one notable exception.

Nextcloud, which I use as a partial G-Suite replacement, is still only compiled for Intel based macs which require Rosetta 2 in order to run. This wouldn’t be that big of a deal as Rosetta 2 seems to be pretty seamless, but there are several reports of huge amounts of CPU usage by the Intel version of the app. Because Nextcloud is always running in the background, this isn’t a “once and awhile” issue.

Several enterprising folks with a little help from the Nextcloud team have successfully compiled a version of the client side Nextcloud app for Apple Silicon. Building on the work they put together in Github thread I was able to get a working installation, but it took some finesse. For anyone who wants to get a version compiled themselves, here are the specific steps I followed:

1. Install Homebrew

If you don’t have it installed, open up a terminal and get the excellent package manager homebrew up and running. More information on Homebrew can be found here. You’ll be prompted to download XCode command line tools, and will have to enter your login password to install:

1

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. Set up the working directory

Create a folder in your home directory to build the related packages:

1

mkdir ~/ncsilicon

3. Install Dependencies from Homebrew

Homebrew will save us from having to compile many the dependencies manually. It looks like some people were running a version of Inkscape through Rosetta for icon generation. Inkscape is actually syntax compatible with librsvg, which has Apple Silicon support out of the box:

1

brew install pcre2 harfbuzz freetype cmake librsvg

4. Build Qt5 for Apple Silicon

Even though Qt6.2 was just released with native Apple Silicon support, the Nextcloud application isn’t compatible with it yet. Nextcloud still uses Qt5, and version 5.15 is the latest freely and publically available version. There are newer versions than 5.15 of Qt5 available behind a paywall, but 5.15 works really well for our needs. As there is no Apple Silicon binary available, we have to build it ourselves.

Clone the Qt5 repo and check out version 5.15:

1
2
3
4

cd ~/ncsilicon
git clone git://code.qt.io/qt/qt5.git
cd qt5
git checkout 5.15

Next we need to pull down all the related modules for the build. This will take a while, and is probably the longest step of this whole process:

1

./init-repository

Qt5 actually has a missing header we need to add in order for it to compile correctly. This appears to be ignored by Big Sur’s version of the clang compiler (clang 12), but Monterey (clang 13) complains and fails if you try to compile without it. Add this header with:

1

sed -i -e 's/#include <qpa\/qplatformgraphicsbuffer.h>/#include <CoreGraphics\/CGColorSpace.h> \n#include <qpa\/qplatformgraphicsbuffer.h>/g' ~/ncsilicon/qt5/qtbase/src/plugins/platforms/cocoa/qiosurfacegraphicsbuffer.h 

Best practice is to build in a different folder than your source code, so the commands below create a new folder and get the stage set for the build:

1
2
3
4

cd ~/ncsilicon
mkdir qt5-5.15-macOS-release
cd qt5-5.15-macOS-release
../qt5/configure -release -prefix ./qtbase -nomake examples -nomake tests QMAKE_APPLE_DEVICE_ARCHS=arm64 -opensource -confirm-license -skip qt3d -skip qtwebengine

Assuming no errors are thrown, we’re ready to build. This will take a bit, but not as long as initiating the repository did. We don’t need to run make install here because we built the libraries in the same location we’ll be using them.

1

make -j10

5. Build qtkeychain for Apple Silicon

Now that Qt5 is done, we need to build qtkeychain. Same deal as above, we need to clone the repo and set up a build folder:

1
2
3
4
5

cd ~/ncsilicon
git clone git@github.com:frankosterfeld/qtkeychain.git
cd qtkeychain
mkdir build
cd build

Then build the binary. We do need to run make install here in order for the libraries to be included in the Qt5 folder.

1
2

cmake .. -DCMAKE_INSTALL_PREFIX=~/ncsilicon/qt5-5.15-macOS-release/qtbase -DCMAKE_BUILD_TYPE=Release -DBUILD_TRANSLATIONS=OFF
make install

6. Build OpenSSL for Apple Silicon

Now that qtkeychain is done, we need to build OpenSSL. We need to clone the repo and switch to the version used by Nextcloud (1.1.1):

1
2
3
4

cd ~/ncsilicon
git clone git@github.com:openssl/openssl.git
cd openssl
git checkout OpenSSL_1_1_1-stable

Then build the binary. OpenSSL uses caffinate to build:

1
2
3

export MACOSX_DEPLOYMENT_TARGET=10.13
./Configure shared enable-rc5 zlib darwin64-arm64-cc no-asm
caffeinate make

Copy the libraries you want to /usr/local/lib. Alternatively you can run make install, but that’ll install far more files including documentation:

1
2
3
4

sudo cp libssl.1.1.dylib libcrypto.1.1.dylib libcrypto.a libssl.a /usr/local/lib
cd /usr/local/lib
sudo ln -s libssl.1.1.dylib libssl.dylib
sudo ln -s libcrypto.1.1.dylib libcrypto.dylib

7. Build Nextcloud Apple Silicon

Now that we have installed the dependencies from Homebrew, and compiled Apple Silicon versions of Qt5, Qtkeychain, and OpenSSL, we’re ready to build the Nextcloud desktop app.

First clone the repo and set up a build folder:

1
2
3
4
5

cd ~/ncsilicon
git clone git@github.com:nextcloud/desktop.git
cd desktop
mkdir build
cd build

We need to set up environment variables for the build, these tell the compiler where to find all of the libraries we just compiled such as Qt5 and qtkeychain.

1
2
3
4

export OPENSSL_ROOT_DIR=~/ncsilicon/openssl
export Qt5LinguistTools_DIR=~/ncsilicon/qt5-5.15-macOS-release/qtbase
export Qt5_DIR=~/ncsilicon/qt5-5.15-macOS-release/qtbase
export Qt5Keychain_DIR=~/ncsilicon/qt5-5.15-macOS-release/qtbase/lib/cmake/Qt5Keychain

Now its build time. This will take a little time but nothing too long. We’ll use make install here which will package the application up in the Applications directory.

1
2
3

cmake .. -DCMAKE_INSTALL_PREFIX=/Applications -DCMAKE_BUILD_TYPE=Release
make -j10
make install

8. Start using the native Nextcloud binary!

Go ahead and launch the app and you should be set! If MacOS complains about the app not being from a known developer, hold down the Control button and right click on it, and select “Open”. It will prompt you with a few “are you sure” messages but then you’re set.

9. Optional - Sign the application yourself

If you’re signed up for the developer program and have a certificate, you can sign the app yourself by replacing “YOUR NAME AND DEVELOPER ID” with your organization name and ID, assuming your certificate is installed:

1

codesign --force --sign "Developer ID Application: YOUR NAME AND DEVELOPER ID" --deep --verbose /Applications/Nextcloud.app

Mask wearing is a simple and powerful way to combat COVID, but it is most effective when practiced at scale within populations. Unfortunately mask wearing has become politicized in the United States, and businesses are often in the position of policing and enforcing mask wearing themselves.

Enter the COVID Bouncer - an application which can be used to detect mask wearing without needing to put a real person at risk of exposure. When paired with a door lock, the COVID Bouncer can detect the presence of face masks before allowing entry into a business.

The Bouncer is able to identify people not wearing masks as well as those wearing masks:

It also functions with images that include multiple subjects as can be seen in the examples below:

Tools Used

This project was built using Apple’s development stack, including their CreateML framework.

• The only tools required to use this repository is ther XCode suite, which includes CreateML.
• Roboflow was used during the data preparation phase.

Data Acquisition

The data for this project came from two sources - one dataset compiled on kaggle and one compiled by the Roboflow. Both of these datasets consist of images of people wearing masks and people not wearing masks. Some images include a mix of mask wearing and non-wearing individuals. The Kaggle dataset also included incorrectly worn masks, but those were removed due to low data availability.

• Kaggle Mask Detection Dataset
• Roboflow Mask Wearing Dataset.

Data Preparation

These datasets required some modification to align labels, and to convert from their respective formats to one which Apple’s CreateML expects.

• Modify the annotations to use “with_mask” and “without_mask” as labels
• Remove the “mask_weared_incorrect” label from the kaggle dataset
• Convert annotation component of both datasets from Pascal VOC XML to Apple’s CreateML JSON

I used a 70/20/10 split for train/test/validation for this dataset. The final dataset consisted of:

• 698 training images
• 199 testing images
• 100 validation images

Model Architecture

I evaluated two training methods as part of this model development. Both models were trained for 18,000 iterations, which took ~14 hours per model. I used loss as an evaluation measure for both models, which is an indicator of how far off from correct prediction a model is for a single example.

First I trained a Full Network (non-Transfer Learning) with an architecture based on YOLOv2:

The Full Network training results are below, and resulted in a loss of 1.355

Second I trained a Transfer Network based on Apple’s “Object Vision Feature Print”:

The Transfer Network training results are below, and resulted in a loss of 0.31

Deployment

I used my personal iPhone as my Edge Device. Modern iPhones include a specialized chip for Neural Network processing. I built my iPhone app using a framework available on GitHub here. This framework was an excellent starting point, but I modified the application code to:

• Use the custom model I trained instead of the roadsign detector
• Only highlight objects detected when there is a > 90% accuracy
• Not allow for objects to overlap with each other (ie no detection of both mask wearing and non-mask-wearing)
• Highlight masks in Green, and non-masks in Red

Roadblocks

I ran into some issues with my personal phone not functioning correctly. The app I built functioned as expected in the iOS simulator, as well on older iPhones such as the iPhone X. I expect that this has to do with the camera on the new phones capturing images in a different format.

Next Steps

Next steps for this project are to apply it to live video as opposed to still images. I’ve already developed an application which does this using the Breakfast Detector example written by Apple. I’m not satisfied with the results of this yet.

From a modeling architecture standpoint there is absolutely opportunity to increase accuracy. The simplest way to do this is to procure and train using more data. The dataset I have doesn’t have balanced examples of masks vs no-masks. Fortunately the gap is primarily on the non-mask class, and there are several datasets available which can be merged with my current dataset for a more balanced input.

Hosting Locations

Self-Hosted - Cloud

• Google Contacts | Nextcloud Contacts
• Google Calendar | Nextcloud Calendar
• Dropbox | Nextcloud / Cryptomator
• iCloud Notes | Standardnotes
• Text File | Nextcloud Tasks / 2do
• Lastpass | Vaultwarden
• Pocket | Wallabag
• Feedly | TT-RSS
• TeamViewer | MeshCentral
• Nothing | Firefox Sync Server
• Nothing | Restic Backup to Backblaze
• Nothing | Tandoor Recipes

Self-Hosted - Local

• Nothing | PiHole + Unbound + DoH
• Nothing | PiVPN - Wireguard
• iCloud Computer Backup | NAS Time Machine
• Amazon Cloudcam | DaFang Hacks / VLC / Telegram

I also took this opportunity to move from Gmail to ProtonMail for email. While email can be self-hosted as well, I felt that swapping the very privacy-unfriendly Google service for a trusted encrypted solutions provider (ProtonMail) met my goal.

In 2020 I went through a migration from Traefik 1.7 to 2.4, and took the opportunity to completely revamp my self hosting approach, applications, best practices, security, and more. I’m hosting everything on a Contabo VPS and on a local Raspberry Pi.

Local Raspberry Pi

• Unbound - Local recursive DNS resolver
• PiHole - DNS black hole
• Wireguard (PiVPN) - VPN Access through PiVPN

I bought several cheap Wyze 2.0 Cameras and put the DaFang custom firmware on them this lets me VPN into my home network and connect to network streams from the cameras using VLC on my phone. I have motion detection notifications running through Telegram with stills taken when motion is detected

Contabo VPS - 9 Euro per month, 6 Cores, 16GB Ram, 400GB Storage (SSD)

As part of my security updates, I decided that some services I host had no business being externally accessible, even when they’re behind HTTP authentication. I set up wireguard docker image to allow me to access my VPS over VPN, and then modified wireguard’s Coredns to allow me to access the services I want on the domains I would have previously accessed externally. I followed this guide for that.

Other security updates include moving to official images for everything, leveraging Cloudflare’s proxy service for any web based applications (though some may argue this isn’t as good for privacy), and moving to docker secrets where possible

I also moved to a socket proxy for the docker socket rather than allowing any images (except for the socket proxy itself) direct access to the docker socket.

Everything except fail2ban on my Contabo VPS are sourced from docker images.

Web Applications hosted behind Wireguard VPN

• Portainer - Docker Management
• PhpMyAdmin - Management of a MariaDB database for applications which don’t support Postgres
• PgAdmin - Management of a Postgres database for any applications which do support Postgres
• Redis Commander (Currently Disabled) - for managing my Redis Memcache installation to speed up Nextcloud

Non-Open-web accessible applications

• Docker Socket Proxy - This allows applications to access only the services they need from the socket proxy and nothing else
• Watchtower - Docker image updates, used as Ouroborus is no longer actively updated
• MariaDB - Open source MySQL server for applications which don’t support my preferred SQL server, Postgres
• Postgres - Open source SQL server for applications which it
• Redis - Memcache to speed up Nextcloud
• Restic/Resticker - This is a docker image which contains a parameterized version of Restic, for automated, encrypted, incremental backups. I’m backing up to a Backblaze B2 bucket which is low cost and use based.

Open-web accessible applications

• Traefik 2.4 - used for reverse proxying open-web applications
• Firefox Syncserver (MariaDB) - this is in the process of being moved to Rust, but that image isn’t ready yet. Still using the old python 2.7 version to sync browser settings, extension lists, and bookmarks.
• Wallabag (Postgres) - Pocket replacement, this integrates very well with iOS and allows me to “stash” anything I come across on twitter, reddit, browsing, and more. I also have Wallabag set up as an RSS feed so when I stash something it shows up in my RSS reader.
• Nextcloud (Postgres) - primarily used as Google replacement, and I use it for Contacts, Calendar, Drive, and Tasks/ToDo hosting
• Wireguard - allows me to access internal services via VPN. This is one of the few “unofficial” images I use from linuxserver.io as I don’t think wireguard hosts an official one
• Tiny-Tiny-RSS (Postgres) - Last year the developer created official docker images, so I moved from an unofficially maintained one to the official ones. This consists of a backend and frontend component, as well as an updater cron job. I much prefer this approach as the unofficial image wasn’t static, and was just an older docker image that pulled the latest version of the app from Git.
• Vaultwarden (Postgres) - This is the unofficial bitwarden api/backend/frontend implementation in Rust. I moved from the default sqlite backend to a postgres backend and found that it is now much speedier when updating folders
• Standardnotes Sync Server (MariaDB) - This is the official backend implementation for standardnotes. I was using the Nextcloud Notes before, but wasn’t happy with the mobile app experience (manual sync over webdav in the Notebooks app). The official iOS app is just as seamless as the native iPhone notes app. This backend server was recently re-written in JavaScript (previously Ruby on Rails). I am not using the recommended “script” based implementation here as I prefer more control over containers and architecture, so I’ve implemented the standalone containers directly in my docker-compose file.
• Standardnotes Web App - the web frontend for standardnotes
• Standardnotes Extensions - This is a docker image which contains all the open source extensions for standardnotes. It’s very simple to run, and lets you use several high powered extensions all self-hosted. I forked this and added additional themes and services.
• MeshCentral - This is a complete replacement for TeamViewer, and enables remote access to my devices without needing to use a third party service. The only downside I’ve found here is that there isn’t a native mobile app.
• Tandoor Recipes - App for self-hosting and sharing recipes. With family members spread out this is a great way to connect around favorite recipes and meal planning.

Possible Future Services

• Bookstack
• Papermerge
• Monica CRM
• fail2ban - may move it into a container