We currently only offer the ability to connect via TCP with a secret handshake. Local connections can instead be initiated using a socket (e.g. .ssb-go/socket).
We currently only offer the ability to connect via TCP with a secret handshake. Local connections can instead be initiated using a socket (e.g. `.ssb-go/socket`).
Perhaps the simplest option would be to rename RpcReader to RpcTcpReader and RpcWriter to RpcTcpWriter and create a second set of variants for RpcUnixReader and RpcUnixWriter.
My current feeling is that this may be an undesirable amount of work (and change) for what is essentially a 'nice to have'. We are already able to communicate successfully over TCP. The main offering of Unix socket communication is a lowering of the overhead; the secret handshake would not need to be executed on each connection, nor would the box stream need to be created.
I am therefore shelving this change for the time being. I may at some point implement a Unix socket-only client just for fun.
Reporting back on some investigations into this:
The short story is that supporting Unix socket connections will require a non-trivial suite of changes to kuska and golgi.
kuska expects the reader and writer streams to be wrapped in `BoxStreamRead` and `BoxStreamWrite` (https://github.com/Kuska-ssb/ssb/blob/master/src/rpc/stream.rs#L143), this means that we can't simply plug a `UnixStream` into the `RpcReader` and `RpcWriter` `struct`s.
Perhaps the simplest option would be to rename `RpcReader` to `RpcTcpReader` and `RpcWriter` to `RpcTcpWriter` and create a second set of variants for `RpcUnixReader` and `RpcUnixWriter`.
Not so simple, of course, because then changes would also have to be made to `ApiCaller` (https://github.com/Kuska-ssb/ssb/blob/master/src/api/helper.rs#L97) as well as `SbotConnection` (https://git.coopcloud.tech/golgi-ssb/golgi/src/commit/15c5e77da642460f60fbe75564abaf113201cc59/src/sbot.rs#L33) and `Sbot` in golgi.
My current feeling is that this may be an undesirable amount of work (and change) for what is essentially a 'nice to have'. We are already able to communicate successfully over TCP. The main offering of Unix socket communication is a lowering of the overhead; the secret handshake would not need to be executed on each connection, nor would the box stream need to be created.
I am therefore shelving this change for the time being. I may at some point implement a Unix socket-only client just for fun.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
We currently only offer the ability to connect via TCP with a secret handshake. Local connections can instead be initiated using a socket (e.g.
.ssb-go/socket).Reporting back on some investigations into this:
The short story is that supporting Unix socket connections will require a non-trivial suite of changes to kuska and golgi.
kuska expects the reader and writer streams to be wrapped in
BoxStreamReadandBoxStreamWrite(https://github.com/Kuska-ssb/ssb/blob/master/src/rpc/stream.rs#L143), this means that we can't simply plug aUnixStreaminto theRpcReaderandRpcWriterstructs.Perhaps the simplest option would be to rename
RpcReadertoRpcTcpReaderandRpcWritertoRpcTcpWriterand create a second set of variants forRpcUnixReaderandRpcUnixWriter.Not so simple, of course, because then changes would also have to be made to
ApiCaller(https://github.com/Kuska-ssb/ssb/blob/master/src/api/helper.rs#L97) as well asSbotConnection(Sbotin golgi.My current feeling is that this may be an undesirable amount of work (and change) for what is essentially a 'nice to have'. We are already able to communicate successfully over TCP. The main offering of Unix socket communication is a lowering of the overhead; the secret handshake would not need to be executed on each connection, nor would the box stream need to be created.
I am therefore shelving this change for the time being. I may at some point implement a Unix socket-only client just for fun.