On Sat, 2010-04-24 at 09:00 +0200, Eduardo Lima Mitev wrote: > A have a couple of concerns about your model that you could probably > clarify: > > -) Why do you consider that a core-transport differs from a > UI-transport, to separate them in two different components? In practice, > UI-transports could be used as core-transports and vice-versa in some > cases. (e.g. you can have DBus between two peer cores; a peer doing > long-polling to other peer through HTTP; a web UI connecting to a peer > through secure web-sockets (wss), etc). > It's certainly true that there will be a lot of overlap between core and UI transports (for instance, I expect TCP will be the first for both).
However, the job of a core transport is for the core to communicate with other cores, whereas the job of a UI transport is to expose enough API for UIs to control the core. That's why I think it's worth separating them into discrete components. > -) In the case of web-based UIs, we would have to figure out how to > properly implement the end-to-end encryption when a PGP model is used. I > mean, if a user A encrypts a message for user B using PGP, and B is > using a web-based UI, probably the peer of user B will have to > participate and decrypt the message, before routing it to user's browser > through the HTTPS channel. Solution to this would be to implement some > kind of logic in the Core, to allow "processing" messages as they change > from one transport to another. > By "peer" in "the peer of user B", do you mean "core?" I don't want *any* encryption or decryption of the things that are end-to-end encrypted done in the core. In the case of a web UI, we'll have to figure out how to implement it in javascript or browser plugins. Doing crypto on the core for traffic that operates at a conceptually higher level than the core (user to user versus node to node) ruins the point of end-to-end crypto. > PS: do you connect to our IRC room #social? what's your nickname? My IRC nick on freenode is eridu.
signature.asc
Description: This is a digitally signed message part
