There has been some discussion on psyc://psyced.org/@PSYC about implementing a shared Client Daemon which would act as a proxy for one or more psyc clients running locally on your machine. The daemon would handle low-level details of the psyc protocol and keeping the user linked to a server, then client applications could connect to the daemon when they need to access the network and exiting a client application would not require the user to unlink or close their psyc connection.

<lynX> Then again one of the UNIs jobs is to make bouncers unnecessary, so the job of the Client Daemon should rather be to provide services like files for friends, while no obvious GUI is running, whereas the UNI does the housekeeping (which may need some improvements there, as we talked about elsewhere.. programmable UNI etc)... I also understand that given this architecture, el is right, that the Client Daemon can be available for P2P operations without even being steadily connected to the UNI.. Still, I cannot imagine we can implement a Client Daemon which would be completely unable to communicate with the end user once there is no GUI running. On a windows dimension it does have to be able to open a pop-up when something happens, doesn't it? Hmm..

PSYC over Unix Socket

11:37:15 20after4 fragt: lynx: I can write raw [[PSYC]] to a [[Unix Socket]], isn't that what the previous mozilla protocol handler was for? The one in cvs?
11:38:01 lynx exclaims: yes.. it was intended for [[psycion]] to receive psyc: link clicks from a browser
11:39:27 lynx exclaims: with our current paradigm of showing the psyc: page first and having function buttons on it
11:39:45 lynx exclaims: you'd have to pass the commands back to the psycion
11:39:53 lynx exclaims: instead of just the urls
11:40:09 lynx exclaims: should be fine
11:40:31 20after4 mumbles: yeah...well what I really was thinking of, socket-wise is to allow non-javascript plugins for psyczilla ...or to allow your console client to connect through psyczilla and share identity
11:41:33 20after4 mumbles: maybe not a worthwhile thing to bother with for the time being
11:42:57 lynx exclaims: in fact yes.. it makes sense for psycion to process the psyc: link click itself
11:43:05 lynx exclaims: fetch the html, give it to the browser
11:43:09 lynx exclaims: then accept commands
11:43:18 lynx exclaims: all sorts of hybrid behaviour
11:44:00 20after4 mumbles: could be done... psycion isn't needed but it could be cool if psycion is more powerful than psyczilla javascript
11:44:10 lynx exclaims: because maybe only one of the two is logged in
11:44:46 lynx exclaims: psycion has an onion routing prototype builtin
11:44:50 lynx exclaims: but no gui for it
11:45:08 lynx exclaims: and native file transfers to go with it

See also: Onion Routing.

Client Daemon

11:45:12 20after4 mumbles: ah, yes...hey that reminds me... I wonder if it would be good to have something that is separate from mozilla maintain the connection, because when closing firefox I want to stay linked to my UNI
11:45:48 lynx exclaims: A BOUNCER!!
11:45:50 20after4 mumbles: if a local daemon could provide psyc: proxy to any gui that wants to use it
11:46:40 20after4 mumbles: it would make things easier also by sharing certain functions and centralizing code in a shared non-gui daemon codebase
11:47:02 20after4 mumbles: when one of our projects implements something cool the other projects can benefit too
11:47:44 20after4 mumbles: but it would have to be cross-platform since psyczilla wants to be compatible with windows. mac and unix
11:48:02 20after4 mumbles: though I could live without windows it's a big userbase
11:52:03 lynx exclaims: the best suited app to this plan is [[perlpsyc]]
11:52:23 lynx exclaims: as el has split psycion user interface in a clean way from the "abstract" client
11:52:29 20after4 mumbles: true, perl is good, cross-platform and suited to the job quite well
11:52:31 lynx exclaims: so a client daemon is feasible like that
11:52:41 elmex spritzt: hi
11:52:51 20after4 fragt: plus perlpsyc is fairly mature, right?
11:52:51 lynx exclaims: we just need anyone willing to compile a win daemon out of it
11:52:55 lynx exclaims: yes
11:53:27 20after4 mumbles: well I can try...but I don't know how to do perl
11:53:39 20after4 mumbles: I'm good at c# and windows development though
11:53:41 lynx fragt: but how do the gui and the daemon communicate?
11:53:47 20after4 mumbles: through a socket
11:53:53 lynx exclaims: thus, no API
11:53:55 lynx exclaims: just psyc methods
11:54:15 lynx exclaims: this would introduce the need for new gui methods
11:54:27 20after4 mumbles: yes, I'm thinking transparent psyc proxy with extra functions so that the gui can ignore some psyc details and just use the local psyc proxy daemon
11:54:39 lynx exclaims: perlpsyc has a nice gui API, but it has no psyc interface for it
11:54:53 20after4 mumbles: hmmm...

xpi Software Installation rocks

11:55:09 lynx exclaims: well i also like how i just installed [[psyczilla]] on my windows
11:55:15 20after4 mumbles: we should not worry about this too much for now because it might be quite some work and delay to set it up
11:55:15 lynx exclaims: i clicked upgrade firefox
11:55:19 lynx exclaims: then i clicked on xpi
11:55:23 lynx exclaims: only had to allow the host
11:55:25 lynx exclaims: that was it
11:55:39 20after4 mumbles: yep...and there are psyczilla updates via rdf feed
11:55:47 20after4 mumbles: supports updating in the extension manager
11:55:53 lynx exclaims: this could even work in office zones where installing your own sotware is forbidden
11:56:57 20after4 mumbles: yep
11:57:03 lynx exclaims: so the potential merits of a psyc client daemon are interesting, but not always wanted
11:57:19 20after4 mumbles: firefox extensions are installed locally in the user-profile so it doesn't require windows admin privileges

Custom UNI

11:59:29 20after4 mumbles: what we need is a basic psyc c2c/p2p spec that we can work from when implementing a daemon/proxy app.
12:00:43 20after4 mumbles: I'm also interested in the idea of writing a custom implementation of the UNI. There is discussion of implementing a chatroom server in perlpsyc, is it possible to implement external UNI in a similar way? I think it would be cool to be able to write external version of User.c
12:01:27 20after4 mumbles: or perhaps a [[procmail]] style feature that would let psyced redirect some things to a file/socket for processing by external apps
12:01:51 fippo hotzenplotzt: we need [[bugless]] to write that feature ;-))
12:02:09 20after4 mumbles: there are things that I think about implementing as psyczilla plugins that would be better as psyced plugins
12:02:38 20after4 fragt: we need bugless psyced you mean?
12:03:10 fippo hotzenplotzt: no, i'm talking about the original author of procmail
12:03:16 20after4 mumbles: oh..hehe
12:03:18 20after4 mumbles: yeah
12:03:32 20after4 mumbles: of course, and lack of bugs would be nice too..haha
12:04:34 20after4 fragt: you know how places each have their own [[LPC]] code? is there a way to write an lpc object for my uni on psyced or does each user have to use the same user.c?
12:05:08 20after4 mumbles: I can write lpc but it would be nice to have custom code for my UNI without editing psyced built-in code
12:14:59 lynx exclaims: programmable users are on the agenda for psyced, yes

Using tags to deal with redirections

12:08:52 20after4 mumbles: hey lynx: bug that I don't know how to fix: when clicking on psyc://ve.symlynx.com/~lynX I get a reply from psyc://psyced.org/~lynX and the message doesn't map back to a browser html page correctly because my callback is waiting for the other uni address
12:09:26 20after4 fragt: can we offer a _source_alias type list so that I can map it correctly?
12:14:25 20after4 fragt: is xmpp:user@host  a valid uri scheme?  doesn't it need to have the double-slash in there after xmpp: ?
12:14:31 lynx exclaims: 420: you get the _tag back
12:14:47 lynx exclaims: so if you map the _tag_reply to the _tag you sent, you find out who's answering what