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.
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.
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…
I’m thinking of maybe doing this over a remote server REST API served by BASH.
- Encrypt notification text in some way.
- Send encrypted notification to the server in a wget POST.
- Accept messages and save them in a file using a timestamp as the file name.
- Accept message requests returning the contents of every timestamped file older than the timestamp provided in the request.
- 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.
- Poll server every 30 seconds requesting every message after the timestamp of the last request.
- If new messages are available, decrypt them and pipe to notify-send
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
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:
# Add to top:
# 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)
# Append the following:
summary = "*"
script = "dunst-notification"
Build a test script for handling notifications
mkdir -p ~/.local/bin
chmod 755 ~/.local/bin/dunst-notification
# Paste the following:
# 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:
(I’ve modified the
dunst styling a bit from the default)
The contents of ~/notification-log.txt should look like this:
Body=This is the text body of the notification.
Pretty cool, huh?
I have to disagree with you…
This thread is clearly very exciting. Nice work! Love it!
LOL! @Ethanol, this made me smile. Thank you.
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.
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
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/
chmod 600 ~/.config/sendapp/key
# Do some crunchy password generation in place of "PASSWORD"
PASSWORD >> ~/.config/sendapp/key
Encryption may look like this:
--output - \
--cipher-algo AES256 \
--passphrase-file "$HOME/.config/sendapp/key" \
<(echo "Message here")
-----BEGIN PGP MESSAGE-----
-----END PGP MESSAGE-----
# ^ Deliver stdout to sharing server via wget post request
Currently thinking about inter-communication options when neither device knows where the other is.
- Assumption the notification repo is malicious
- Easy for anyone to set up and hack on
- 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.
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.
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.
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.
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.
Network Notifications Betwixt Devices for Linux
Inter-Device (with Linux) Notifications over Network
I tried really hard to incorparate DLN haha
Pusher of Wideband Notification daemon
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.
This is a supremely excellent “just make it work” self-hosting option for pushing messages around. Very impressive.