Looking into it more, you do apparently need to connect to a channel. sorry for the noise.

However, you can easily create a users: channel that does not require any special auth:

  def join(<<"user:", id :: binary>>, payload, socket) do
    if socket.assigns.user.id == id do
      send(self(), :after_join)
      {:ok, socket}
    else
      {:error, %{reason: "unauthorized"}}
    end
  end

.. or similar.

and then you can broadcast to the channel. Is there a specific reason you are avoiding connecting to the channel?

Channels do not create an extra network connection. They are multiplexed over the socket. On the server-side channels are quite cheap. So I wouldn’t worry about that.

You might try running <YourApp>.Endpoint.subscribe("<some_topic>") from within the connect/2 callback. Supposedly, it would run inside the process handling the socket. Then you would be able to broadcast to all socket processes subscribed to "<some_topic>" with <YourApp>.Endpoint.broadcast("<some_topic>", some_event, some_msg) and see where it gets you. If phoenix’s socket is just a handler module for cowboy, you might be able to use cowboy’s callbacks to handle incoming messages, which IIRC is websocket_info, which seems to be forwarded to handler’s ws_info in phoenix v1.3 and to handle_info in phoenix master.

if there is no good API then one really should be PR’d in to handle arbitrary unhandled messages to the socket PID

It seems like handle_info has been added as a possible callback to phoenix.socket in v1.4. But in v1.3 the messages are simply ignored unless you pack them in a {:socket_push, _, _encoded_payload} tuple.