I am a shit webdev who hasn't done much desktop application programming, so while I know the theory of IPC methods, I am not well versed in the ins and outs of IPC.
This idea ain't new. Phones have been doing it for a while, mainly because it stringly suits its usecase, but I think desktops could benefit from this. Basically, at least in Android, certain apps "register" their capabilities and semantics to let the rest of the system know they can provide services complementary to what the user is working on at the moment. The nost obvious example is the share menu, in which you can pass any piece of media in any application to any other "Share protocol" compliant program. You can use this to message an image you just found in your web browser to a friend via your IM app of choice, but obviously you could do more than that.
In desktops, we have similar mechanisms, but they are more limited. For example, we have the "default programs" and MIME types mechanisms, which open certain types of links or files with a single program of choice, but it's not as flexible considering I don't always want to use mutt to share an image with a friend, specially considering I may have several friends who don't use the same IM programs.
So what the fuck am I trying to ask with this? I am trying to ask whether there are any projects which focus on standarizing capabilities and communication between programs running in the same computer. This may seem superfluous and too "UX" at first glance, but there are serious implications about this. You know how the fucking GTK file dialog you get eith Firefox still doesn't have a decent image preview in the $CURRENT_YEAR? Yeah, why can't we use a decent file picker? I am going to assume it is because the file picker is part of the GTK library, not a separate program of its own, which is very UNIX-unlike. If we managed to let the system know we want to use a filepicker of our own, we could circumvent this; you may argue this could be achieved by registering filepickers as a default program, just like you would with mail programs for mailto links, and you would be right, but why not go even further? If we manage to make the IPC robust and flexible, we could make it able to share more than just the path of the file you want to share, and you could share the file itself, via pipe or whatever, which means a huge security improvement. Firefox, for example, has no fucking right being able to have full read-write access to your files. However, you still want to be able to read and write files, under your own command only. You could share the file itself with Firefox despite being completely isolated as a different user or inside a nazi sandbox, using a different non-isolated process to pick the files you want to share with Firefox. This could be easily achievable if the file picker (say, a modified pcmanfm) registers itself as a "file provider" in the global "IPC services" table, which would make it elegible to provide this service; Firefox would send a signal to the IPC services manager/server or the file picker itself to open a "file picker" capable program in "provider mode", which means it has to return whatever it provides to the requester. It's a relatively simple UAC that would greatly improve flexibility, security, isolation, and even reduce bloat, so I don't know why I don't see this shit more often. From the little I have understood of dbus, it looks similar to this, but its obviously not used for this purpose, so I don't know what the fuck it's used for. I guess this is what it was designed for, but it's not used for this, so I don't know why there could be a reason the community is opposed to standarizing common information sharing usecases.