As for systemd, I gathered there was a connection to kdbus, which was Lennart's baby. Thusly, I gathered it needed init to cooperate, the same way kdbus did, and any non-bus1-aware init just wouldn't work with apps that used bus1.
As for portability, what other OS will implement this muck? None of them. It's portable the same way systemd is: "apps that depend on us are portable, so long as every os copies all our stuff, and re-implements all our APIs"
Forcing other OS's to implement your stuff isn't portability.
But if bus1 is a successor to kdbus, it's not intended to be used by low-level userland, it's built for highlevel userspace. Like systemd, this is trying to coax high-level userland to be incompatible with other unixes.
The fact that no unixes other than the originating one, if the orginator was a unix, has picked up any of these systems speaks volumes about why you shouldn't use it in highlevel userland.
You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc.
bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic.
When I said that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...
The fact that Bus1 doesn't need init cooperation is good.
However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than DBUS.
As for kdbus not being Lennart's baby, and that I should look at who wrote the code, I did. I direct you to https://lwn.net/Articles/580194/, where Lennart not only takes credit for KDBus, but also says it's application-level, implying it is intended to be used in high-level userland.
High-level abstractions for applications don't belong in the kernel.
There is no sealing in bus1.
The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish.
kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween.
High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.
The whole point of capability based security is that there is no permission system, because permissions are implicit in the capabilities. So this is much simpler than e.g. SysV message queues.
As to portability, this is a linux kernel module, but there is nothing really inherent to linux about it, so porting it to another kernel should not be a lot of work if that is interesting to anyone.