03:42 <isd> TimMc: poked a friend today. The issue I was remembering was that the other CAs won't cross sign for wildcard certs. It might be more feasible once all the browsers trust letsencrypt directly

03:42 <isd> TMM: not sure what you mean by 'non ez'?

03:49 <isd> (The cross-signing thing is apparently in their charter somewhere)

08:25 <trypo> can someone help me to configure rock.chat to link to dolphin platform ?

09:15 <TMM> isd, the examples only use the 'ez rpc' interface

13:08 <TimMc> isd: Ooooh, interesting.

19:03 <TMM> Does anyone have a link to a full api doc for capnproto?

20:57 <kentonv> TMM: there isn't a reference doc but the headers are well-commented

23:05 <LilianMoraru> Hello

23:06 <LilianMoraru> I want to use the Rust implementation of Cap’n Proto and I am curious if the RPC works over TCP or shared memory?

23:08 <LilianMoraru> I saw that the official site mentions shared memory but I have not seen how I can differentiate between these. I want to know if I want something like Cap'n Proto Serialization + Nanomsg(and loon "Time-Traveling") or the RPC already supports this. #dwrensha

23:09 <LilianMoraru> lose on "Time-Traveling"*

23:19 <dwrensha> LilianMoraru: the RPC works over any futures-enabled byte streams

23:19 <dwrensha> https://docs.capnproto-rust.org/capnp_rpc/twoparty/struct.VatNetwork.html#method.new

23:20 <dwrensha> now that tokio-io is a thing, twoparty::VatNetwork::new() ought to take an AsyncRead and an AsyncWrite, rather than a Read and a Write as it does now

23:24 <dwrensha> in the next version (0.9) I'd like twoparty::VatNetwork::new() to take a futures::Stream and a futures::Sink, rather than a Read and a Write

23:29 <dwrensha> LilianMoraru: I've only ever used it over TCP and Unix sockets

23:38 <LilianMoraru> I see, so it expects something that implements the trait, it so happens that TCP already does that

23:39 <LilianMoraru> From what I understand, all that is needed is for the protocol to implement the correct interfaces

23:39 <LilianMoraru> #dwrensha Thanks for the answer

23:40 <dwrensha> https://docs.rs/tokio-io/0.1.1/tokio_io/trait.AsyncRead.html

23:41 <dwrensha> ^ this documentation is relevant

23:41 <dwrensha> the AsyncRead trait acts as a "marker" that a Read object is futures-aware

23:41 <LilianMoraru> Yes, the one announced recently

23:42 <dwrensha> if you pass non-futures-aware I/O objects to capnp-rpc-rust, you'll get deadlock

23:42 <LilianMoraru> I see

23:43 <LilianMoraru> Currently neither nanomsg.rs nor scaproust implement it

23:45 <LilianMoraru> Thanks again. I think I'll try to see if scaproust can be converted from mio to futures

23:46 <dwrensha> sounds like you are trying to use capnp-rpc-rust on top of nanomsg?

23:46 <dwrensha> ... which sounds like a bad idea to me

23:54 <LilianMoraru> I see, why?

23:54 <LilianMoraru> Because it is blocking?

23:54 <LilianMoraru> .recv() and .send()

23:55 <LilianMoraru> Hmm, maybe you mean the layer of indirection...

23:55 <LilianMoraru> Instead of using shared memory directly...

23:55 <LilianMoraru> Actually, yes, the API might not map well