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!