Hello! I like what I see so far with pushbits. Thanks very much for creating it. How I am using it:

• Compiled my own docker image using the Dockerfile, for Raspberry Pi, to run on my ARM processor.
• Using with Element web client (Firefox web browser) and Element app on iOS (iPhone)
• I am able to create users and applications fine using pbcli. I can send messages fine using curl to the created application for the Matrix user.

I noticed the following:

• When an application (Room) is created via pbcli, encryption for the Room is not enabled.
• I manually enabled encryption for a room in Element.io's web app: Click "..." to right of Room name in Room list->Room Options->Settings->Security & Privacy->Select "Encrypted" slider to enable
• After enabling encryption for the room manually via Element.io's web app, messages sent via my local pushbits server show up with a red exclamation mark. Hovering the mouse cursor on that the pop-up text indicates, Unencrypted
• When I click on the unencrypted message in the Element iOS app, it shows:
  Curve25519 identity key
  none
  Claimed Ed25519 fingerprint key
  none
  Algorithm
  unencrypted

I am wondering why messages I send to my local pushbits server, are not relayed to Matrix using end-to-end encryption. Would it be possible to enable this in some way?

I also noticed when I built my own local Docker image that there was a warning in the SSL certificate section (in bold below). I wonder if this could be contributing to the lack of encryption. Thank you for any information you could share... much appreciated.

FYI, I modified the first line in the Dockerfile to the following: FROM arm32v7/golang:alpine as builder

 $ docker build -t pushbits .
Sending build context to Docker daemon  116.7kB
Step 1/15 : FROM arm32v7/golang:alpine as builder
 ---> 3acd86eb4cf4
Step 2/15 : WORKDIR /build
 ---> Using cache
 ---> 013fad3eabff
Step 3/15 : COPY . .
 ---> Using cache
 ---> 81c54ab0cc6c
Step 4/15 : RUN set -ex         && apk add --no-cache build-base        && go mod download      && go mod verify        && make build   && chmod +x /build/app
 ---> Running in 7a1c4aa05b65
+ apk add --no-cache build-base
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/armv7/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/armv7/APKINDEX.tar.gz
(1/20) Installing libgcc (10.2.1_pre1-r3)
(2/20) Installing libstdc++ (10.2.1_pre1-r3)
(3/20) Installing binutils (2.35.1-r1)
(4/20) Installing libmagic (5.39-r0)
(5/20) Installing file (5.39-r0)
(6/20) Installing libgomp (10.2.1_pre1-r3)
(7/20) Installing libatomic (10.2.1_pre1-r3)
(8/20) Installing libgphobos (10.2.1_pre1-r3)
(9/20) Installing gmp (6.2.1-r0)
(10/20) Installing isl22 (0.22-r0)
(11/20) Installing mpfr4 (4.1.0-r0)
(12/20) Installing mpc1 (1.2.0-r0)
(13/20) Installing gcc (10.2.1_pre1-r3)
(14/20) Installing musl-dev (1.2.2-r0)
(15/20) Installing libc-dev (0.7.2-r3)
(16/20) Installing g++ (10.2.1_pre1-r3)
(17/20) Installing make (4.3-r0)
(18/20) Installing fortify-headers (1.1-r0)
(19/20) Installing patch (2.7.6-r6)
(20/20) Installing build-base (0.5-r2)
Executing busybox-1.32.1-r3.trigger
OK: 137 MiB in 35 packages
+ go mod download
+ go mod verify
all modules verified
+ make build
go build -ldflags="-w -s" -o app ./cmd/pushbits
+ chmod +x /build/app
Removing intermediate container 7a1c4aa05b65
 ---> 495b734259a3
Step 5/15 : FROM alpine
 ---> 6ecc03ee95e9
Step 6/15 : ARG USER_ID=1000
 ---> Using cache
 ---> 023eb4422549
Step 7/15 : ENV PUSHBITS_HTTP_PORT="8080"
 ---> Using cache
 ---> aa898ce7fa9f
Step 8/15 : EXPOSE 8080
 ---> Using cache
 ---> abad2f4ff353
Step 9/15 : WORKDIR /app
 ---> Using cache
 ---> c94eb019b244
Step 10/15 : COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
 ---> Using cache
 ---> 8726a5d408b9
Step 11/15 : COPY --from=builder /build/app ./run
 ---> b44e07535f24
Step 12/15 : RUN set -ex        && apk add --no-cache ca-certificates curl     && update-ca-certificates        && mkdir -p /data       && ln -s /data/pushbits.db /app/pushbits.db     && ln -s /data/config.yml /app/config.yml
 ---> Running in ce0654bbb2d6
+ apk add --no-cache ca-certificates curl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/armv7/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/armv7/APKINDEX.tar.gz
(1/5) Installing ca-certificates (20191127-r5)
(2/5) Installing brotli-libs (1.0.9-r3)
(3/5) Installing nghttp2-libs (1.42.0-r1)
(4/5) Installing libcurl (7.74.0-r1)
(5/5) Installing curl (7.74.0-r1)
Executing busybox-1.32.1-r3.trigger
Executing ca-certificates-20191127-r5.trigger
OK: 6 MiB in 19 packages

+ update-ca-certificates
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping

+ mkdir -p /data
+ ln -s /data/pushbits.db /app/pushbits.db
+ ln -s /data/config.yml /app/config.yml
Removing intermediate container ce0654bbb2d6
 ---> bc69a4cf8780
Step 13/15 : USER ${USER_ID}
 ---> Running in ce7fe59f5fd8
Removing intermediate container ce7fe59f5fd8
 ---> 3ab00d75901c
Step 14/15 : HEALTHCHECK --interval=30s --timeout=5s --start-period=5s CMD curl --fail http://localhost:$PUSHBITS_HTTP_PORT/health || exit 1
 ---> Running in a6bc57a94b6e
Removing intermediate container a6bc57a94b6e
 ---> 65f07b171d20
Step 15/15 : ENTRYPOINT ["./run"]
 ---> Running in 837aa9b5cb9f
Removing intermediate container 837aa9b5cb9f
 ---> cbdc45f9e44b
Successfully built cbdc45f9e44b
Successfully tagged pushbits:latest

Gotify and Pushover both have a collection of examples for sending notifications with their product. It probably makes sense for us to showcase similar examples for PushBits.

When binding the structs for updating users and applications, unbound struct members will inherit the default initialization values. Currently, this means that when a value is not supplied, it will be reset to that default value.

If someone doesn't want to run PushBits behind a proxy, this feature enables them to still use HTTPS. Shouldn't be too difficult using Gin's RunTLS function.

As CPU parallelism increases over time, parameters of key derivation function should be tweaked. Also, administrators should use the strongest feasible parameters for their environment.

Currently, the server takes that whatever it reads from the database as given. However, some entries could have changed over time while the server was offline, or rendered obsolete for another reason.

For instance, a user could have left the room for some application. The server should detect this, and either

• delete the corresponding application, or
• reinvite the user to the room.

Hi,
first of all I would like to thank you for developing such a great piece of software, really appreciate your work on this and make heavy use of Pushbits! :)

Now to my issue:
I've noticed is that the Topic is reset to Application n when restarting the container. Is this done on purpose? Could this be changed since it would be nice to set a custom topic that is not changed back to the application number.

I also have two side question, wouldn't it make also sense to ship CLI with the server container too since this would make the usage from the container much easier by simply connecting to the console from the container and issuing cli.
Would it be okay for you if I create a Unraid template for your container so that people are able to easily set up your container?

Many Regards,
Christoph

I think most importantly, authentication errors should be generic. Also, usernames could be made case-insensitive.

We can use SendFormattedText() to send messages with formatting.

Would be cool and should be relatively simple.

Possible Golang XMPP libraries to use:
https://github.com/mattn/go-xmpp (used by Matterbridge, quite stable)
https://github.com/FluuxIO/go-xmpp

Thanks for considering. If you need help setting up a text XMPP account let me know :)

Make a better API documentation. I think there are to much endpoints to do that in a (sinlge) Markdown-File anymore.

Either split it up into multipe files (and use the github wiki functionality) or use another tool for api documentation.

Don't trust all proxies

Health checks are useful for monitoring the deployment. This feature will require a new routing endpoint.

logrus is quite awesome. I think we should use it to visually highlight errors from informational messages.

High-quality software needs good testing. If this project should ever be used in production, tests are a must.

Having E2E in Matrix is nice, but to make it effective against active attackers requires that the keys are verified. As a first step, we need to implement an API endpoint and make use of it in the CLI tool.

Some people might prefer Telegram over Matrix as a notification backend. Since Telegram has an extensive API as well, the backend could be made configurable.

Alertmanager is a popular alerting gateway especially build for prometheus environments. Grafana, a popular data visualization tool, lately added alertmanager into their product. It allows to send alerts to a generic endpoint as a json-formatted HTTP request.

We could use this to broaden the usecase for PushBits further by adding an endpoint that can handle those alerts and forward them to a matrix channel. This will be quite simple to achieve since we only need to properly parse the alerts and then can throw them into the existing message flow.

Currently one would need to add an additional tool like Alertmanager to Gotify Bridge to the stack.

First thanks a lot for pushbits!

I installed it and tried sending message using the example curl command. While message are fully working on riot.im, on my phone (element-ios) however I do get message notification
(bubble count increases) and the source user pops in the chat on new message but each message content is empty and there's no title to messages.

Is this somehow related to pushbits?

In Gotify, users can choose between plain text and Markdown using a message extra.

The application needs to be created in the database so that an ID is available.

We can either

• remove the application ID from the topic, or
• create the application in the database before creating the room.

In the latter case, we need to take special care of handling errors during room creation.

Docker will be the primary way of publishing this project for now. As a requirement, we need a minimal Docker image.

Hi

Since version 0.8.4 the Docker image doesn't seem to work anymore:

2022/04/15 10:04:01 Version not set
panic: Version not set

goroutine 1 [running]:
log.Panic({0xc00039ff50?, 0x446531?, 0xc000088710?})
        /usr/local/go/src/log/log.go:385 +0x65
main.main()
        /build/cmd/pushbits/main.go:48 +0x7a

I'm guessing it's reletated to these changes:

• 3a48352
• 86971a5

Maybe the git describe --tags command in the Makefile isn't working as expected during the build of the image?

Hey, how can i post a simple message plus matrix handle to a pushbits server to send to from js?
Or how does the json needs to be structured exactly? (whats the token, is it required?)

To state it differently, my usecase is this: i want to send a message and a receiver "@user:matrix.org" to a server and the server should just relay the message to the receiver, can pushbits do that? :)

As discussed in #58, is it possible to include cli in the Docker image because you can then open up a container console and add applications directly from the container without going through the hassle downloading it on a physical machine or even to the container.

For the first release, no user interface other than a CLI is planned. The CLI tool will communicate via the API.

Could either use this crate or implement the API interaction from scratch.

Not sure why I looked for a crate 😄

PostgreSQL is a great database, but I haven't found time to implement this yet.

Hy,

I have already successfully added an application that works perfectly. Now I wanted to add a new application, but every time I enter the password for authentication I get the following message: "FATA Request failed with HTTP 500 Internal Server Error."

The current application can be displayed without any problems.

Does anyone here have any ideas?

We can do this with GoReleaser as we already do for the CLI tool.

Add options on how text should be formatted in Matrx, e.g. HTML, plain text, ...

I already mentioned this in #21, but wanted to open this separate issue to let you know that this is a really important feature for me and to letting you know, that I am planing on implementing that myself and then opening a PR for that. So we do not work on the same feature.

Either we disallow this to happen completely, so a user is bound to its Matrix ID, or we kick the existing Matrix ID and invite the new one.

Gotify offers an option to delete messages. I'd like to see something similar in pushbits. But instead of deleting messages I'd prefere some sort of highlighting or reply.

One could use rich replies for that. Unfortunately reactions (those little emojis under a message) doesn't seem to be specified anywhere currently.

The event_id needs to be returned from /message endpoint as a identifier for the message.

Could leverage, e.g., syft.

Semgrep could help us find and prevent obvious security issues.

We should have image tags for versions.

docker/metadata-action looks interesting. Also check out the GitHub documentation.

Currently, applications and users can only be created and deleted. In a more complex environment, it would help if applications and users were editable.

In the configuration I used the format that was documented for the admin matrixid, which is: @xyz:matrix.org. When I try to create a new app, I get this on the server side:

INFO Registering application pushover, notifications will be relayed to user xyz:matrix.org.
INFO failed to POST /_matrix/client/v3/createRoom: M_UNKNOWN (HTTP 400): Invalid user_id: xyz:matrix.org

Does pushbits require the account to be discoverable? Just fyi, I've already logged in as the account specified in matrix.username and created a room with the account specified in admin.matrixid. Could this cause an issue?

Thank you!

I was thinking of Argon2 or scrypt.

Without any admin user, the instance becomes unusable.

Hi,

pushbits looks quite interesting, and the idea of having /alert work with AlertManager is pretty cool!

For simpler use cases like sending a notification from a shell script, a simpler endpoint would be nice.
Is this something that has been considered?

When an application is renamed, the channel name remains the same.

Most importantly, we should enable authentication via, e.g., OAuth bearer tokens, and support 2FA.