Rich presence

[Leeo97one]

How can we let Discord be notified by some rich prensence-compatible software? I guess it is more than just adding --filesystem=/proc.

[mjarkk]

Same problem here

After some digging in things that use discord's rich prensence i found they use a Websocket or a sock file.
Most programs use the sock file located at /run/user/1000/discord-ipc-0 (at least when not ran in a container)

Things i have tried to make it work:

• --filesystem=/proc --filesystem=/run and --filesystem=/proc --filesystem=/run/user/1000 it will give a lot of errors probably because of incompatteble packages and other related things
• --filesystem=host, --filesystem=/proc --filesystem=/run/user/1000/discord-ipc-0 and --filesystem=/proc --filesystem=/run/user/1000/discord-ipc-* that also doesn't seem to work. discord rich prensence tells me it fails to connect probably because there is no file/dir created named discord-ipc-0
• --share=ipc, --share=network and --socket=system-bus will give errors, take long to start discord or just do nothing special

Some things i have found that maybe cause this to not work...

• That number at the end (0) can be different according to the nodejs Discord.js RPC Extension
• In that same file i see a view request to http://127.0.0.1 on port 6463 to 6472 (this is also dune in the Websocket connection file) discord's webserver might be also sandboxed with the result that you can't connect to discord
• the discord-ipc-0 file might be not in /run/user/1000/ because that file gets placed in one of the following folders: $XDG_RUNTIME_DIR, $TMPDIR, $TMP, $TEMP or /tmp

If someone want's to dive deeper than me here are maybe some usefull docs:

• flatpak sandbox permissions
• flatpak sandbox permission reference
• nodejs Discord.js RPC Extension

My system details:

• OS: Fedora
• uname -r: 4.17.3-200.fc28.x86_64
• Display server: Wayland

[TingPing]

• Exposing /proc at all is just broken conceptually and shouldn't be done.
• Exposing xdg-run/discord-ipc-* is not possible without exposing all of xdg-run which his just broken and shouldn't be done.

I don't see a reasonable solution to this sadly.

[gasinvein]

What apps (or Steam games maybe) actually use discord rpc? I'd like to test this.

[mjarkk]

@gasinvein
I used https://github.com/iCrawl/discord-vscode to test it because the code is fully open source and you can see what it's doing.
That VScode extensions is build on top of: https://github.com/iCrawl/rpc if you want to dive deeper inside the code (This gives you probably more inside to what is happening than the extension)

Here is a list of other things that use or have something to do with discord's Rich presence but i have no experience with these packages or how they work..

• Arom Discord
• Sublime Discord RP
• osu
• Virtual Trucker Rich Presence on Discord
• call of duty ww2
• Documentation

[gasinvein]

@mjarkk Well, I've managed to get it working with this tricks:

1. Bundle socat into Discord flatpak
2. Run discord with --filesystem=xdg-run/discord:create
3. Inside sandbox, run socat UNIX-LISTEN:/run/user/1000/discord/ipc-0 UNIX-CONNECT:/run/user/1000/discord-ipc-0
4. In the VS Code flatpak, create a symlink /run/user/1000/discord-ipc-0 → discord/ipc-0, then run VS Code

[mjarkk]

@gasinvein amazing!!
I'm definitely gonna use that trick.
If no-one makes a flatpack package with this this included i'll probably make one myself with your fix

[gasinvein]

While it can be automated via wrappers, It's very hackish, especially because it requires modifications to all rpc-using apps, not just Discord.
Check out my fork and build it if you wish.

@TingPing your opinion?

[TingPing]

@gasinvein Placing it in xdg-run/discord sounds acceptable to me. It would be best to have a discussion with upstream Discord about this in general though. Of course I see no reason for them to actually care but maybe we get lucky.

[gasinvein]

@TingPing If it's acceptable to start socat in background from Discord's wrapper, I'd open a PR.

I see no reason for them to actually care

Even if they'd care, changing socket path means breaking existing clients, so they definitely wouldn't do this.

[TingPing]

Even if they'd care, changing socket path means breaking existing clients, so they definitely wouldn't do this.

Obviously they could keep both around for compat, deprecate the old one, and slowly move apps over.

@TingPing If it's acceptable to start socat in background from Discord's wrapper, I'd open a PR.

As long as you make sure it dies with discord.

[TingPing]

@gasinvein I enabled the wiki on here, could you make a page about Rich Presence and how to get it working with host apps and other sandboxed apps?

[gasinvein]

Maybe a readme would be better?
For host apps it's enough to do ln -s discord/ipc-0 $XDG_RUNTIME_DIR/discord-ipc-0.
And for other flatpacked apps it's required to also add --filesystem=xdg-run/discord:create. I think it's better to create the symlink via wrappers, so apps maintainers should be asked for this.

[TingPing]

We can make the README point to the wiki. I just think thats more convenient.

[gasinvein]

@TingPing done, sorry for my bad english.

[phaux]

It doesn't work for me. There's nothing discord-related in $XDG_RUNTIME_DIR (/run/user/1000)

[alauracarlotta]

Boa noite,

eu estou tentanfo entrar mas eu não estou conseguindo. Funciona pra Linux tamabém?

[KHALILK23]

DISCORD RPC IS NOT WORKING

[Hacksore]

FWIW in flathub/flathub#5450 I'm able to connect to RPC over websocket without issue.

I suspect that flatpak doesn't have as strict implications on the 127.0.0.1:[6463-6472] websocket compared to the unix socket documented here.

[lionirdeadman]

FWIW in flathub/flathub#5450 I'm able to connect to RPC over websocket without issue.

I suspect that flatpak doesn't have as strict implications on the 127.0.0.1:[6463-6472] websocket compared to the unix socket documented here.

Right, the share=network (https://github.com/flathub/com.discordapp.Discord/blob/master/com.discordapp.Discord.json#L17) permission allows for full network access - both internet and local. It would be nice to separate the two but this is not the case.