Re: [jdev] Re: Local proxy for multiple applications
So I made a prototype - withuot any real functionality, without any security, with only guesswork using regexps instead of real parsing, but I managed to use it to connect using Psi trough it (withou any change in psi code, just by setup) and insert other messages into the stream. One day, when it will be finished, it would be better if application knew about it, but it will tolerate even the stupid ones.. So, if is anyone interested in it, it can be found at svn://pretel.cz:6400/protoxy. If you want to connect trough it, configure the client to connect to localhost:5252 instead of the real server and have a look at init.xml. (it needs to change the values, there is a password in the ugly looking long line as well). Then start the thing and connect by a client. You can open another connection and listen what is incoming and send whatever you like to the server. But it does not do anything like filtering, where a stanza belongs, nor it does any security things, like TLS and it uses plain-text password, so do not use it with your ususal account. There is even a small script to insert a message from command line, xmpp-message. It needs Qt4 to work. If you don't find a bug, then you do not look ;-). But feedback on the idea is welcome. This prototype is not ment to work, it mey not even connect to server and will not know about it and so on.. Dne sobota 22 duben 2006 14:30 aliban napsal(a): interesting :) well, just as I am curious, do you think this could become part of KDE/Gnome one day? Basically the concept is similar to mine with XCD but I was not using D-Bus. Neither was me and will not. ;-) Anyway it would be nice if it can be intergrated into a desktop like KDE, in example you could browse (disco) with konqueror to xmpp:// - konquerer extension could then offer GUI for the xmpp features offered by a server/client/component. In this case it could be integrated into Kopete as well ... In Kontrollzentrum you could also add a config feature. Well, you can use it with any client (well, will be able to, today, it is quite too much dumb and is not too much XMPP compliant, as it is only prototype) and use it to insert other comunication without need to do things like authentication (well, there will be something, like need to send a cookie present in uset environment, to protection) and just send and receive what you need. After this, there is no problem integrating it with some really simple code into anything (if you just sent a iq and only waited for response, you could use usual DOM parsers for that). But I am sure you know about this already... regards [EMAIL PROTECTED] Robert McQueen schrieb: Michal Vaner (Vorner) wrote: Dne pátek 21 duben 2006 19:49 Magnus Henoch napsal(a): I haven't looked at it myself but Telepathy might be a place to start: http://telepathy.freedesktop.org/wiki/ I was about to make a pointer to our project. I'm one of the lead developers on the Telepathy project, and although slightly off-topic for this list, I thought I'd at least answer this seemingly unfaor appraisal of our efforts to date. Why do simple things in complicated way? Because it's not a simple thing. If you want to create a protocol which can act as proxy for any arbitrary real-time communication protocol you care to name, trying expose less complexity to client authors who don't care about the perculiar features of a given protocol, but not restricting the extensibility of those who do, it's absolutely not a trivial problem. It's similar in form to the problem which XMPP itself aims to solve (making a protocol which is extensible enough to gateway on to other protocols and extend with new features), and you can hardly say the overall result of that is simple, but we've decided to use D-Bus as our basic transport because it has bindings to most popular object systems (glib, qt, python, perl, c#...) that make coding against it pretty easy to get going. If you want something which *is* simple, and discards all of the features of different networks, perhaps Bitlbee would be what you wanted. Everything then becomes just an IRC network where you can only send/receive plain text, but it's just not what the goal of the Telepathy project is. And why the hell not separate different things as much as possible? We are all in favour of this. Our goal is that protocol code is seperated into backend D-Bus services. Front-end clients which implement particular functionality like managing your contacts, text chats, voice calls, file transfers, etc, interact with different objects provided by these backend services. Different communication types are split out into different objects - we have a Connection object which represents your server connection, from which you can request or be given Channels to perform communications over, of the various types I've mentioned. Why not use sime pipe or network socket directly? Because
[jdev] Local proxy for multiple applications
Hello, I was thinking this way: There are apearing some applications that do some tasks and their primary purpose is not comunication. However, they comunicate using jabber. (inkskape for example, if I remember well). Users want games in IM clients, which has nothing to do with IM. UNIX filosophy tells to separate different tasks into separate programs. So yes, it would be possible to separate the games into different programs, which would be just called from the client with right info (where to connect, which user try to contact and everything). However, this would mean the game mush have full supprt for things like XML parsing, SASL, TLS and everything. It would mean another connection to server as well, which would mean more load on server, need to keep the connection using whitespace pings (which means more pings with more connections) and another resource appears for other users. So I was thinking about something like is X server. On a user login, it would start and connect and provided kind of user proxy for all his application, making it only one connecion and making the life for applications a bit easier by handling the SASL, TLS, transparent merging of more accounts together, and more extensions like file transfers, jingle and so on. It would mean even transparent handling of history, regardless if it is server-side or client-side, support of new features for application which did not have it before (like it would be possible to add encrypted sessions to all applications without them knowing about it, for example). Another advantage would be, if the graphic frontend crashed (and the graphic application tend to do so more oftenly then simple text ones, I don't know why), you would not lose your last messages and messages got on the last moment, you could just start the app again and it would get them, and other users would not even know something happend to you. Of course, the design would need to be done more properly, but I wanted someone to comment on this a bit, if it is a good idea. I'm sending it here, because I think it has nothing to do with standards, it is just another way for a design for client software. If you think otherwise, I appologise and would move it to better mail list. Thank you. -- NAT should extinkt like dinosaurs did. Michal Vaner (Vorner) pgpMFK7xqRvVS.pgp Description: PGP signature
Re: [jdev] Local proxy for multiple applications
Dne pátek 21 duben 2006 18:52 Justin Karneges napsal(a): On Friday 21 April 2006 08:52, Michal Vaner (Vorner) wrote: someone to comment on this a bit, if it is a good idea. I'm sending it here, because I think it has nothing to do with standards, it is just another way for a design for client software It is a good idea, and not a new one either, but so far it hasn't really caught on. There have been a couple of attempts at a client daemon, the most recent being Edrin's xcd for Windows. I'd like to revive this idea sometime in the future, but I'm not sure when. -Justin Well, seeing the emerging aplication to use jabber in some ways (inkskape, there is some discusion on koffice...), it may be the right time. Alright, so I will try to think about how it would look like and make some kind of prototype with limited functionality. Actually, it was an idea as something I would like to do as summer of code project, but someone would have to mentor it for me. (and I would have to find out if the high school I'm leaving in about a month would provide me with the papers that I'm a student). As a demonstration, I would maybe add some kind of really primitive command line client that would use some of it's features. -- NAT should extinkt like dinosaurs did. Michal Vaner (Vorner) pgpFkMr6os4yq.pgp Description: PGP signature
Re: [jdev] Re: Local proxy for multiple applications
Dne pátek 21 duben 2006 19:49 Magnus Henoch napsal(a): I haven't looked at it myself but Telepathy might be a place to start: http://telepathy.freedesktop.org/wiki/ My god, not another DBus monster! :-O Why do simple things in complicated way? And why the hell not separate different things as much as possible? Why not use sime pipe or network socket directly? I wanted to provide just a proxy, that would be able to filter the stanzas out, send them to server and allow some more control using some other XML. But not move all the ways of comunication to some daemon and not be able to send custom data that are not supported by the procedure of RPC for sure? Why does all the freedesktop projects seem to me as an attempt to make linux as bad as windows? :-( Sorry if I may seem as an extremist here, but this seems to me as a bad thing. This would disallow the extensibility of the protocol, if used. -- NAT should extinkt like dinosaurs did. Michal Vaner (Vorner) pgpSEqigIV6E4.pgp Description: PGP signature
Re: [jdev] invisibility on servers with no jabber:iq:privacy
Dne úterý 04 duben 2006 20:58 Vinod Panicker napsal(a): On 4/5/06, Robert McQueen [EMAIL PROTECTED] wrote: Peter Saint-Andre wrote: Some servers support the old-style presence tyle='invisible'/ (which was deprecated for various reasons when we published the XMPP RFCs). Yes, but Google Talk doesn't support this *or* jabber:iq:privacy. If I send presence type=unavailable/ to gtalk, then it still sends incoming presence to me, and only allows incoming messages if I've sent outgoing messages to that person. Is this normal, or Google-specific? This behaviour would be against the RFC. The RFC states that presence notifications are to be sent to available resources. By sending presence of type unavailable, the resource goes into the active state. In this state, the server should not be delivering it presence notifications, nor messages. Yes, we should ask them to fix it. And even better, to support other required thinsg, like jabber:iq:privacy and even the usual services, like offline messages, private xml storage and vcards. Byt yes, I know it is still beta :D But now seriously, I'm glad google is pushing XMPP to 'normal' users, and I thank it for that, but it could do a bit better picture - the offline messages would be nice. -- Ostatně soudím, že uzavřené protokoly a formáty by měly být zničeny, stejně jako Kartágo. Michal Vaner (Vorner) pgpayUOjgZlph.pgp Description: PGP signature
Re: [jdev] Question about resource binding to server implementors
Dne úterý 28 březen 2006 07:06 Vinod Panicker napsal(a): Hi, Just wanted to check with the server implementors - Do you allow multiple connected resources with the same resource identifier? According to to specification, resource must be unique, therefore it is not allowed to have two same resources. If yes, how do you handle delivery of iq/ stanzas addressed to the full jid of the user. If no, how do you handle it when a client connects with a resource identifier that is already in use? There are three possible ways on the server, two on the client side. On the client side, the client may set the resource to something or let the server choose something for him. On the server side, it is possible to drop the old (which is more logic, it can be some hanging connection that did not timeout yet), drop the new one or change the wanted resource. Yes, server can return different resource than client asked for and in this case, it may be a good solution sometimes. Regards, Vinod. -- Ostatně soudím, že uzavřené protokoly a formáty by měly být zničeny, stejně jako Kartágo. Michal Vaner (Vorner) pgpW8OEkIX9Sb.pgp Description: PGP signature
Re: [jdev] Re: JEP-0027 (OpenPGP) implementation question
Dne neděle 05 březen 2006 21:04 Norman Rasmussen napsal(a): On 3/5/06, Remko Troncon [EMAIL PROTECTED] wrote: On 05 Mar 2006, at 18:26, Norman Rasmussen wrote: No, as I said: as Michal pointed out any exchange of pgp/gpg keys in-band will be insecure. (e.g. using the same tcp connection). The keyservers are the 'right' place to store and get this information. Retrieving keys from a keyserver is equally unsecure. I think there's a mixup between the issue of automatically exchanging keys, and actually asserting that the key is valid. The former requires no security at all and can therefore be automated, the latter requires extensive checking. Agreed, gpg/pgp keys are 'supposed' to be inheriently strong, and therefore no automatic retrieval/exchange should even/ever be done, ever. If people want to implement automatic key exchange, they should be looking to implement JEP-0116 - it's actually far safer in terms of not being able to add and remove messages from conversations, additionally if the private key is ever compromised, then the messages can not be read. In fact anyone wanting to implement encrypted communications in their clients should be implementing JEP-0116, and _not_ JEP-0027 - is backwards compatability with older clients a good enough reason to implement something that's tricky to set up and get working with contacts on your roster? In my opinion, it should be implemented both. Firstly, by use of GnuPG, it is much simpler, secondly, many old client will still use gpg ant there is need to communicate with them. And, other problem is, JEP-116 is still experimental. Not much clients will support it until it is a draft. -- Windows are like windows - shiny, but fragile and expensive Michal Vaner (Vorner) pgp00V7uyNxCS.pgp Description: PGP signature
[jdev] Reason for jingle/google talk inconsistency
Hello, I do not know, if this is the right place for this question, but I was wondering for some time, what was the reason for making the jingle protocol, while very similar to google sessions, different by only the name of XML element and the namespace. Actually, I do not see, how could google then change it all. Therefore, other clients will support either both or just the google session, I guess. If I'm completely mistaken, please excuse me and correct me. Thank you. -- Windows are like - windows - shiny, but fragile Michal Vaner (Vorner) pgpxVa36DKxuH.pgp Description: PGP signature
Re: [jdev] JEP-0027 (OpenPGP) implementation question
Hello, the point with PGP is that user checks and signs the key (if he trusts it). Therefore, key exchange can not happen automatically, since it would break one of the main idea of PGP, that user knows who he is encrypting to. Dne sobota 04 březen 2006 21:25 Juan Antonio Gómez Moriano napsal(a): Hello to all. I'm making a Jabber client whose main important thing is that it implements the JEP-0027 (Current usage of OpenPGP in Jabber), i already know properly the protocol, and i have read the JEP-0027 (http://www.jabber.org/jeps/jep-0027.html) . The question is that the document does not specify very clear (IMHO) how to perform the key exchange it says : All keys are exchanged using OpenPGP key servers, and usually are retrieved when a signed presence/ stanza is received (key retrieval does not happen in-band). The thing is : how do i know in which server is the key of the person i am chatting with?? Also it would be great also if someone can give me an opinion about using GnuPG for doing this: I am doing all the development in JAVA and i will prefer to avoid using an external program (as GnuPG). Apart from that, I have been doing some testing with encryption over jabber by using the own Jabber server to exchange the keys (just to check that i did the encryption part properly, and it worked, using RSA keys...) Any idea/suggestion/hint?? THANKS in advance. -- Ostatně soudím, že uzavřené protokoly a formáty by měly být zničeny, stejně jako Kartágo. Michal Vaner (Vorner) pgpFaQlCLXOV8.pgp Description: PGP signature
Re: [jdev] Presence probe question
Dne pátek 10 únor 2006 13:23 Vinod Panicker napsal(a): Hi, According to RFC 3921, section 5.1.3, point 4 - Else, if the contact has at least one available resource, the server MUST reply to the presence probe by sending to the user the full XML of the last presence stanza with no 'to' attribute received by the server from each of the contact's available resources (again, subject to privacy lists in force for each session). Taking this into consideration, lets look at the following scenario - - contact and user are in each other's rosters, with a subscription type of both - contact sets presence as busy - contact sends a directed presence to user, type away - user's server sends a presence probe to contact - contact's server returns the last presence stanza received with no 'to' attribute - busy I think that the contact's server should send the last directed presence received for the user, if applicable. WDYAT? Regards, Vinod. Hello, if I got it right, the probe should be sent by the server only in the ocassion that the user just connected and the server does not yet know the foreign user's state. If the foreign user sent a direct presence, the user was not connected ad it got dropped. Therefore I think the situation you describe will not happen.But I can be easilly mistaken. -- Windows are like.. windows. Shiny but fragile and expensive. Michal Vaner (Vorner) pgpTZY79ThSlG.pgp Description: PGP signature
Re: [jdev] Privacy feature
Dne neděle 05 únor 2006 08:49 Trejkaz napsal(a): Hi all. I've been looking at knocking together a simple privacy list management webapp, which might eventually be of use for all those poor people whose clients don't support it directly. One of the things I just noticed is that ejabberd doesn't list jabber:iq:privacy as a feature in service discovery, but jabberd2 does. I'm pretty sure ejabberd does support the feature since it claims 100% XMPP compliance now, but if it doesn't list the feature then what is the proper way to detect its existence? XMPP, If I read it properly, does not say it should be listed in the features. Instead, it says that privacy lists are required, so client sould not detect the server can do that, client should expect them to do so. If not, the server is not XMPP compliant and you will get feature not implemented error when you try do use them. -- Windows are like.. windows. Shiny but fragile and expensive. Michal Vaner (Vorner) pgp5QRBBZExLb.pgp Description: PGP signature
Re: [jdev] Privacy feature
Dne neděle 05 únor 2006 10:59 Trejkaz napsal(a): On Sunday 05 February 2006 19:52, Michal Vaner (Vorner) wrote: Dne neděle 05 únor 2006 08:49 Trejkaz napsal(a): Hi all. I've been looking at knocking together a simple privacy list management webapp, which might eventually be of use for all those poor people whose clients don't support it directly. One of the things I just noticed is that ejabberd doesn't list jabber:iq:privacy as a feature in service discovery, but jabberd2 does. I'm pretty sure ejabberd does support the feature since it claims 100% XMPP compliance now, but if it doesn't list the feature then what is the proper way to detect its existence? XMPP, If I read it properly, does not say it should be listed in the features. Instead, it says that privacy lists are required, so client sould not detect the server can do that, client should expect them to do so. If not, the server is not XMPP compliant and you will get feature not implemented error when you try do use them. So basically what you're saying is, the only way to find out is to try and then get an error, because: 1) a server might be 100% XMPP compliant, and simply allow the privacy list feature to be disabled, or; Then the software might be compliant, but the server is not. Compliant server must support it and have it available. Therefore, what does not provide this is not compliant. 2) a server might not claim to be XMPP compliant at all, and still support the feature. It may be missing something else, therefore it would not be compliant for other reason. IMO, it would be useful if there were a way to find out if a feature exists before trying to use it (like we have for almost every other feature.) Then you would have to provide a way to test if the server allows sending stanzas and everything. The protocol would get incredibly complicated if you tested just any feature. In every protocol, there is some base that can not be tested, protocol states it is supported by anything, so why to test it? Would it make logical sense to say it is supported by any server and then allow client to test if it is? I think it is more useful to show an error message about non-compliant server and users will ask the server owner to support it than client that silently ignores it. -- Windows are like.. windows. Shiny but fragile and expensive. Michal Vaner (Vorner) pgpR0fgmtMYmE.pgp Description: PGP signature
Re: [jdev] Hi
Hello, I'm currently working on some small utils for jabber as Open Source. I write it in C++/Qt, with an attempt to make it cross-platform. My current project is Jaboard - jabber draw board, something like MSN whiteboard, but as a stand-alone program. If you do not want to think of something new for yorself, you may want to have a look at http://sisel.pretel.cz/ (or, in english http://sisel.pretel.cz/english/). Dne pondělí 02 leden 2006 01:50 Sathish R napsal(a): Hi friends, I am new to this mailing list and jabber. I like to develop something interesting using jabber (as a hobby). But there are many clients and servers. Is there anything new that can be done with jabber? If anyone has any ideas, pls share with me. (I am interested in c/c++ development in linux environment). Regards, Sathish R Have a nice day -- Windows are like.. windows. Shiny but fragile and expensive. Michal Vaner (Vorner) pgpE9j0JqBufR.pgp Description: PGP signature
Re: [jdev] Conference messages multicasting
Dne pondělí 26 prosinec 2005 10:26 Ulrich Staudinger napsal(a): Oleg Motienko schrieb: Hello, I asked such question last year, but didn't got answer at that time. So, if N users of my xmpp server talking in MUC on other server, each user get copy of each message in conference, and I guess S2S traffic will be N*messages_size ? Is there any S2S feature which can send one copy of message body to many users with same domain like CC: in email ? Hi Oleg, afaik there isn't. But it's a good point ... It would reduce the traffic cost among high load distributed environments in big distribution by factors. As I know, it exists - extended addressing, or how is it called. However, I do not thing it is supported by software. If you have both servers that support it, it can send messages with are addressed to more than one recipient, so there would be N addresses and the message only once. -- Windows are like.. windows. Shiny but fragile and expensive. Michal Vaner (Vorner) pgpR1dZpOHM4d.pgp Description: PGP signature
