I'd rather make PushMessage non final and remove the interface; value objects should not be final.

Should I change it?

that's what I think

im willing to, but notice that said implementing an interface first introduce a contract and secondly allow implementation vs extension which its always good

My experience is that interfaces are needed to abstract services, but here we are representing data. A value object, thus a class, is SOLID enough to me.

i have not found on the doc or on the code anyway to pass options to the transport from the notifier service, I can only do it using a new notification and that blocks me because of the message as explained above

PushMessage constructor accepts options as a third argument, so your transport could define options on it's own and then in the asPushMessage method you could do something like:

if ($transport === 'pusher') {
  $options = (new PusherOptions())->channels(..);

  return new PushMessage(.., $options);
}

And in the transport you could check if that option is defined then use it to make api call

got it. I can close this now but I advise to look at the options to include interfaces or drop the final on value objects as Nicolas propose

Putting a final on a class that is referenced by an interface is an API-design bad practice to me, because it kills any extensibility. I'm still for removing the keyword.

agreed and done