Yeah sure! I will create a Phoenix example very soon. Perhaps by the end of tomorrow. The tokens come from PushManager. I will add a better explanation and a code example to clarify further.

Yup! In compiled BEAM files, including both Erlang and Elixir, module names are just atoms, and both can cross-call each other. Elixir’s namespaced Module.Names are just fancy wrappers around compile-time verified and alias-friendly atoms.

Elixir, designed after Erlang, has the luxury of making calling Erlang module cross-calls as elegant as :module_name.function(). To do something similar from Erlang you have to deal with the more ungainly 'Elixir.Module.Name':function() syntax. This is why Elixir libraries “supporting” Erlang better will often simply defmodule Module.Name and then implement a defmodule :module_name that defdelegates to Elixir functions, to make it nicer to call from Erlang as module_name:function().

I also think “Erlangifying” an Elixir library involves making it support rebar3 in practice, but I have no experience on this front.

Yeah, the JOSE library that you use does exactly that, you can take a look at the code. It’s way easier to use Erlang from Elixir, than the opposite. If you write the core in Erlang, you have the guarantee that someone somewhere in a basement some time in the future will be grateful

Other remarks:

• you force the use of HTTPoison upon the user. An alternative is to use Tesla and let the user choose its favorite HTTP library (example). Another option is to write a behaviour for HTTP requesting and let the user implement its own (and / or provide with a default implementation securely using for instance httpc). I’d normalize the success response as well, now it’s {:ok, %HTTPoison{}} but what if you change the library in the future? Does the response actually contains something useful?
• many modules seem to be for internal use - you can add @moduledoc false to prevent having them in the doc
• I would have let the user handle batch sending notifications, as Elixir has all the needed primitives for that, and there might be other ways to do it (if you want “at least once” delivery then you’d probably use Oban). Thus I’d remove ExNudge.send_notifications/3
• It seems to me ExNudge.generate_vapid_keys/0 is used at config time. Maybe a Mix task would be more useful? I think other Web Push libraries do that
• I personnaly like when errors are returned in the {:error, Exception.t()} form: exception are better documented (example), can have a default error message, additional information and in case you don’t know what to do with them you can just throw (raise) them away

Cheers!

Great, thanks for the contribution!

I have a few questions:

• How does this library differ from web_push_elixir and web_push_elixir?
• Have you considered making it compatible with Erlang for our Erlangist friends? Looks like it pretty low level, and I can see some needs to use it in Erlang directly. (I myself regret I didn’t do it for wax thinking it was too complicated - it’s not. And not long ago I couldn’t use https://github.com/discord/manifold in an Erlang project, had to rewrite it.)
• I see this library uses application configuration, which is a anti-pattern. You might be interested in reading this page. You might be interested in a wider community review?

Cheers!

One of the considerations i had before building this library was web_push_elixir but I ran into some issues while using it. Unfortunately I don’t really remember what the issue was there (perhaps it was compatibility with Arc), but after going though the code I noticed some inconstancies with RFC 8292 . I haven’t compared the encryption and everything one-to-one but one major difference were the headers. The RFC describes the usage of the authorization header using the “vapid” key and “t=? k=?” as a value, whereas the library implemented something different, perhaps RFC 8291. I have also added minimal concurrency and telemetry. I also want to expand it a bit to allow at least retries of failed requests and callback functions. For example cleanup callback that removes certain subscriptions from the database when they expire and creates a new one in place, I can use rate limit with exponential backoff and fallback to email notification, perhaps if a message is too large a retry with shorter message can be useful and so on.

I never even thought of making it compatible with Erlang. I know I can “import” Erlang code into elixir but I had no idea the reverse was possible as well. I will take a look. Thank you for the suggestion!

I will take a look at the anti-pattern thing as well. What do you mean by wider community review? But yes, that is part of the point of this post. I want to understand where I’m lacking knowledge, wether or not my library makes sense for the community and get to know fellow elixir developers

Thank you for your time!