Checklist

• [x] I have read the Contributor Guide
• [x] I have read and agree to the Code of Conduct
• [x] I have added a description of my changes and why I'd like them included in the section below

Description of Changes

The /run/user/x/discord-ipc-y no longer seems as accurate as previously and fails to connect. /run/user/x/com.discordapp.Discord/discord-ipc-y does work though.

sudo netstat -l -p | rg /run/user/ still lists the old path though: unix 2 [ ACC ] STREAM LISTENING 586043 376511/Discord --ty /run/user/1000/discord-ipc-0 So I would expect to find the socket when running ls /run/user/1000 which I don't. I checked the file descriptors directly of the pid: ls /proc/376511/fd | rg 586043 and do find the socket: lrwx------@ 64 oskar 25 Nov 12:56  36 -> socket:[586043] Confirming it's a unix socket: sudo grep -slw 586043 /proc/net/* /proc/net/unix

I don't really now why that socket can't be found so instead of completely replacing I added it as a fallback. I suspect the same thing might be happening on Windows so want to confirm that before merging this. In that case I can fix Windows in the same pr.

Checklist

• [X] I have read the Contributor Guide
• [X] I have read and agree to the Code of Conduct
• [X] I have added a description of my changes and why I'd like them included in the section below

Description of Changes

After working with this crate in a recent project, the largest headache I encountered was the lack of ability to set just a start timestamp on activity (to get the (xx:xx elapsed) message in my status).

This PR adds two new methods to ActivityBuilder and slightly changes IntoTimestamp and Timestamps to add this ability.

I have added ActivityBuilder::start_timestamp and ActivityBuilder::end_timestamp which both set only their respective timestamp values when called. ~~I have also deprecated ActivityBuilder::timestamps (although this can be undone)~~, and changed its code to just call start_timestamp and end_timestamp. (Important note, calling both methods together will set a time range, like timestamps does)

Both the start_timestamp and end_timestamp now take a generic T: IntoTimestamp instead of an impl IntoTimestamp since the Rust compiler seems to dislike the old way, throwing errors when the method is called.

I have added an IntoTimestamp impl for i64, so crate users can easily enter a unix timestamp as an integer (more useful for testing than anything).

Finally, to make setting only one timestamp at a time possible, I have added serde annotations to Timestamps to skip serialization of empty fields.

I'll be keeping an eye on this PR for any requested changes, or comments.

Related Issues

None

Checklist

• [x] I have read the Contributor Guide
• [x] I have read and agree to the Code of Conduct
• [x] I have added a description of my changes and why I'd like them included in the section below

Description of Changes

Discord app registration was broken on at Win 11 (unclear if it worked on previous versions) due to the verbatim prefix (\\?\) that was added to the exe path. Apparently this isn't supported when the path with the prefix is saved in the registry as the shell open command. It would simply fail to open the registered app.

I also compared to some other games I had registered and tweaked the DefaultIcon location (+ path to strip the prefix) as well as some other register key values to more closely mimic how the "official" registration is done. Code for the official version can be found here.

Tested on Win 11 and could confirm the app launched correctly

Even though Voice is being deprecated, we're hoping to use Lobbies in the short term to get voice chat support. This works well, but one missing piece is that when joined to a lobby voice channel, you hear everyone, and everyone can hear you, which is fine for internal playtests, but might be a bit tedious with real users. Adding support for the Voice API in the SDK would allow us to add support for self muting and un/muting of other players in the lobby.

Gives relationship_update events their own activity type to avoid future differences between the formats, still sharing some types though.

Also fixes an issue where timestamps converted from Discord's i64 representation, which is in milliseconds, but was converted as if it was in seconds. :stuck_out_tongue:

Also fixes an issue where the strings such as state and details in the SET_ACTIVITY command must either be null/missing or else have something other than whitespace.

Resolves: #13

"{"cmd":"DISPATCH","data":{"type":1,"user":{"id":"123414231424","username":"name","discriminator":"52","avatar":"f62f2a755cb18c94dc5cda94441024f1","bot":false,"flags":0,"premium_type":0},"presence":{"status":"dnd","activity":{"assets":{"large_image":"spotify:ab67616d0000b273d1e326d10706f3d8562d77f8","large_text":"To the Moon"},"created_at":"1628629162447","details":"To the Moon","flags":48,"id":"spotify:1","name":"Spotify","party":{"id":"spotify:216453179196440576"},"session_id":"6bb1ddaea510750e905615286709d632","state":"Rob Curly","sync_id":"2qZFCu2kYtAagNQA7NZfCq","timestamps":{"end":"1628629327961","start":"1628629161811"},"type":2}}},"evt":"RELATIONSHIP_UPDATE","nonce":null}"

This hasn't been officially announced by Discord yet, but the Voice, Lobbies, and Networking functionality will be deprecated and removed sometime in the future. Since only the lobbies functionality has been implemented thusfar, we will mark that functionality as deprecated once it is official.

cargo-release unfortunately calls the hook before it modifies any files, so just made my own script to do the release and file copying before tagging and pushing.

Large refactoring both internally in the SDK but also the whole repo in order to have isolated examples that can have their own dependencies, but can still be run with a simple cargo run --example <name>.

This also adds some "helper" DiscordHandler implementations both for testing and "real" usage which are now used in tests/examples.

Adds a super simple LobbyStates helper that can be used to maintain the state of the lobbies as events are sent from Discord to show the state of members/metadata/etc. Users can use this or roll their own if they want to, unlike the official SDK which maintains the lobby state itself and has awkward methods to read the state from the SDK.

Added 2 more examples:

• repl - A simple CLI you can issue commands in to do things like create lobbies, update activity, etc
• overlay - A simple egui/OpenGL application to attempt to show overlay stuff. I still wasn't able to get Discord overlay to work on Windows, but hey, I tried!

We're currently using a fork of tokio 1.7 to add some needed methods to NamedPipeClient as it is brand new in 1.7, this is necessary for us to be able to publish new releases.

This adds the base groundwork for replicating the official SDK as well as (mostly) complete implementations of the Activities, Lobbies, and Overlay portions of the SDK.

The current implementation is largely hands off, meaning that it is up to the user to manage the actual state, unlike the official SDK. For example, if you create a lobby, and wanted to present the state of the lobby in a UI (the users in the lobby, whether those users are speaking, what messages had been sent to the lobby, and any metadata associated with the lobby or the users) you would need to keep the state of the lobby updated with all of the various events (member connected/disconnected/updated, member start/stop speaking, lobby updated) to accurately represent the complete lobby state as Discord would see it.

One other thing, we are using a fork of tokio as named pipe support on Windows is extremely new, and was missing a few small methods that we need to be able to use the same exact I/O loop code on both Unix and Windows without having to have a separate special path just for Windows.

Since Discord themselves don't provide any kind of headless test server for RPCs, there's no good way to do automated testing in a normal headless environment since it requires installing the full Discord app, and logging into it, which, AFAICT, is impossible in a headless environment as Discord doesn't support command line arguments.

While testing locally in a regular desktop environment works, this is tedious and easy to miss stuff, especially from outside contributors, so I think it makes sense to make a unix domain socket/named pipe server that tests can fill out with preplanned responses/events to add a bit more sanity checking to CI.