The following sink providers are currently planned:
file - provider that allows to write events to a file
syslog - provider that allows to write events to syslog

The proposed "proxy" provider is very similar to the future "remote" provider.
The "remote" provider is supposed to send the events over the wire to the central location.
The proxy sink provider will instead send the events to a local daemon. This local daemon would effectively be solving the same problem as syslog providing ability to write to one destination (most likely file). It would be extremely useful in cases when there is a pool of worker processes or threads that do same thing and thus use same ELAPI configuration and same application name. Those would compete for the same file or other resource they are configured to write their logs to. To avoid that interlocking issue these processes should be configured to use a proxy provider. The proxy provider will send events to the daemon that would receive the event and write it to whatever destination it should write it - for example file.

The internal implementation of the communication between the proxy provider and the daemon is TBD.
From the surface it seems that the options are: UNIX sockets or shared memory.
The daemon itself will listen on the socket get events and using ELAPI write it into its destination.