Inter-device notifications for Linux over a network?

For example if a Website posts a standard DBUS notification or I use…

notify-send "hey there!"

is there something already made for Linux that can make that show up on both my laptop and pinephone simultaneously?

I can also use dunst to run custom commands for notification messages if there’s a solution which isn’t specifically designed for Linux or isn’t for DBUS notifications.

edit:
This also needs to work over the Internet with changing public IPs as the devices are seperated and move around.

This is a rush answer as I’m about to rush out the door for a trip…

Is the pinephone on the LAN? or cell data network? does it use X11? You could send the message twice: once to the local machine and then to the remote device.

You’ll need ssh privileges to the remote device.

ssh -X user@remote_device_ip DISPLAY=:0 notify-send “Yo!”

I don’t have time to test it – but this might get you started on a working solution.

1 Like

Yeah that’s a damn good answer depending on the circumstance. Doesn’t get more elegant than that.

I’ll add this to my post but I need it to work while the two devices are separated by the Internet and the public IPs won’t always be the same as both devices move around.

Riffing off your solution I supposed I could have them talk SSH through a server. Maybe by depositing a file for reading or tunneling over a port forward. I’ll have to think about it…

Also enjoy your trip!

I’m thinking of maybe doing this over a remote server REST API served by BASH.

Sender:

  1. Encrypt notification text in some way.
  2. Send encrypted notification to the server in a wget POST.

Server:

  1. Accept messages and save them in a file using a timestamp as the file name.
  2. Accept message requests returning the contents of every timestamped file older than the timestamp provided in the request.
  3. Periodically check the message folder and delete files with a timestamp older than 10 minutes. This gives all devices an ample chance to catch new messages.

Receiver:

  1. Poll server every 30 seconds requesting every message after the timestamp of the last request.
  2. If new messages are available, decrypt them and pipe to notify-send
1 Like

Progress 1: “If you want to catch fish, you have to think like a fish.” ~ Dad advice

The best way to catch notifications appears to be using a custom notifier that replaces the existing one. There’s a few options but I had the most success with dunst.

https://wiki.archlinux.org/title/Dunst
https://dunst-project.org/documentation/

Install and configure

# Remove the current notification deamon, ex: sudo dnf remove xfce4-notifyd
sudo dnf install dunst # Fedora
sudo apt install dunst # Debian/Ubuntu

# Set dunst to run at startup, example method:
vim ~/.xinitrc
# Add to top:
dunst &
# Copy the default Dunst config for user modification
mkdir -p ~/.config/dunst/
cp /etc/dunst/dunstrc ~/.config/dunst/dunstrc

# Log out and back in
# Confirm it works
notify-send "Test notification"
# You should have seen a blue box with white text pop up

# Configure dunst to send all notifications to a custom script (not just a pop up)
vim ~/.config/dunst/dunstrc
# Append the following:
[info]
summary = "*"
script = "dunst-notification"

Build a test script for handling notifications

mkdir -p ~/.local/bin
touch ~/.local/bin/dunst-notification
chmod 755 ~/.local/bin/dunst-notification

vim ~/.local/bin/dunst-notification
# Paste the following:
#!/usr/bin/env sh
Origin=$1
Title=$2
Body=$3
Type=$4
Priority=$5

# Dump the contents of every notification to a text file:
echo -e "===\nOrigin=$1\nTitle=$2\nBody=$3\nType=$4\nPriority=$5" >> $HOME/notification-log.txt
# Test the script from terminal:
notify-send "Test notification"

# Test the script from a browser:
# https://www.bennish.net/web-notifications.html

image

(I’ve modified the dunst styling a bit from the default)

The contents of ~/notification-log.txt should look like this:

===
Origin=notify-send
Title=Test notification
Body=
Type=dialog-information
Priority=NORMAL
===
Origin=LibreWolf
Title=Notification #1
Body=This is the text body of the notification. 
Pretty cool, huh?
Type=
Priority=NORMAL
2 Likes

I have to disagree with you…

This thread is clearly very exciting. Nice work! Love it!

3 Likes

LOL! @Ethanol, this made me smile. Thank you. :slight_smile:

2 Likes

Progress 2: Taking off at a good clip

Adding clipboard support

I realized this project is basically all you’d need to send your clipboard to another machine. I may do this first as it proves the underlying process to make notification sharing work while requiring extremely few extra steps.

Security

Transmission of data needs to be encrypted as clipboard/notifications may contain private info and meddling with the data could exploit vulnerabilities.

There’s about a bazillion ways to encrypt/decrypt something. I’ll try to make it easy to swap in a user’s desired method but the default needs to be something easy for the average user and preferably with no dependencies.

A good solution may be generating a key file somewhere in the user’s home folder with 600 permissions. It’d be used to encrypt/decrypt transmissions and the user would need to install it in every machine. As an optional step this key file could be kept encrypted on-disk using something like pass

Key creation may look like this:

# If the script doesn't see a key file, it'll
# create one with a long and complicated password.
if [ ! -f ~/.config/sendapp/key ]; then
	mkdir -p ~/.config/sendapp/
	touch ~/.config/sendapp/key
	chmod 600 ~/.config/sendapp/key

	# Do some crunchy password generation in place of "PASSWORD"
	PASSWORD >> ~/.config/sendapp/key
fi

Encryption may look like this:

gpg \
--symmetric \
--armor \
--output - \
--cipher-algo AES256 \
--batch \
--passphrase-file "$HOME/.config/sendapp/key" \
<(echo "Message here")

-----BEGIN PGP MESSAGE-----

jA0ECQMC/Phulfyy+5jQBmxC5KzpHXDPsszTrobycxPJr6Up8nDyfAKa6LisNpQr8
edpfHigHSE8eCPmmV+1v0kSsEVS+dGXoZIc3R9PWyzF5n+T3Q==
=pS6c
-----END PGP MESSAGE-----

# ^ Deliver stdout to sharing server via wget post request
2 Likes

Currently thinking about inter-communication options when neither device knows where the other is.

Priorities being:

  • Assumption the notification repo is malicious
  • Easy for anyone to set up and hack on
  • Self-maintaining
  • Lightweight
  • Very high reliability
  • Self-hosted FLOSS-only software

Needing a server

There seems to be no escape from needing a server on a known IP as even P2P solutions need somewhere to negotiate a connection.

An alternative could be using dynamic DNS so the home is on a static IP port forwarding to an edge device that’ll collect and serve the notifications. I’m a little wary of recommend this as a failure in security could produce a beachhead into the home network where-as a cloud solution keeps things off-site so it’s almost certainly going to be a cloud solution build unless someone shows me a P2P miracle.

Hypothetically Matrix may be a good solution but that depends on how much of a pain it’d be to implement.

Routing

Using ncat or socat would be pretty lightweight but they’re not exactly well tested edge solutions and many users may already have a routing software.

nginx is one of the most popular routers for serving web requests so i’ll likely go with that and the implementation can be friendly with working alongside other services.

nginx can also communicate with POSIX Shell and BASH directly which eliminates the need for a bloated AF Web stack and needing to know an additional language. You could even write a Website in pure POSIX if you wanted to (don’t tempt me).

Removing Internet dependency

The idea that the Internet has to work for my calendar software to alert me or to be able to share my clipboard with the computer next to me is not great.

There’s some pretty complicated ways this could be made decentralized but I think the most simple and elegant way would be to just have duplicate systems. An example set up would be deploying this server on both a Digital Ocean droplet and a LAN based Raspberry Pi.

Outbound messages will be given a provable collision free UID and sent to every server in the user’s configuration file if they’re accessible (both droplet and LAN Pi).

Inbound messages will be read from both servers and ones with duplicate UID’s will be ignored.

This would provide LAN based speeds while preserving remote capability without needing to expose a home server as an edge device.

1 Like

I’m in a difficult position.

I decided on nginx with a very lightweight BASH backend running on CentOS with SELinux.

I’m sitting on a finished installation guide and from there it’s just working out the inter-communitcation and storage dynamics which i’ve already mostly mapped out.

…but…

It’s big

It’s a frikkin’ long guide and even though it’s step-by-step most people will lack the technical expertise to do it. It’s also adding the burden of a server to rent and maintain which again is easy for some, not so easy for others.

I could mitigate that a bit by wrapping it into an automated install script but then I have to pick specific OS’s and package versions to support where-as my guide includes troubleshooting tips for multi-os/version compatibility.

Matrix

I’ve gained a lot of experience playing with the Matrix API and it’d make this project extremely easy for anyone to deploy. It only needs curl to use the API. It can also be deployed locally and used in the same way I described last post as a primary, failover, local send-only option or solitary solution.

What’s the furture of IDNFLOAN?

(Inter-Device Notifications For Linux Over A Network)

Firstly it needs a better name, omg.

This is now a Matrix project and the BASH backend guide will be released for Terminal Takeaway after I clean it up at some point.

At the moment I can deliver, retrieve and interpret text over Matrix. I need to produce a more exact communication plan, configurable software for both ends and a user/installation guide.

NNBDL

Network Notifications Betwixt Devices for Linux

iDLNn

Inter-Device (with Linux) Notifications over Network

I tried really hard to incorparate DLN haha

Pusher of Wideband Notification daemon

PWNd

Yeah I can tell this naming thing is going to be a problem lol

PWNd is fun but wideband feels more like a radio thing. Betwixt is just a good word for any occasion. Maybe we should just call it Betwixt. :stuck_out_tongue:

2 Likes