I'd like to use XMPP as the message bus for a desktop application. As the application would use the users existing XMPP account (GTalk or the like) and doesn't provide IM service I would like to make instances of my client invisible to other XMPP clients.
To do this I'm considering using client service discovery and privacy lists to block outgoing presence notifications to the full JIDs of clients other my own. I do however doubt the scalability and robustness of this approach. Is there a better way of accomplishing this?
EDIT:
I'm now thinking the closest I can get to this behaviour is to set a presence of away with a negative priority. This will hopefully minimise user confusion and work fairly universally.
XEP-0126 doesn't have the tools you need, since there's no way you'll find out about the other clients to which you have to direct presence... because they're invisible.
How about if all of your clients join a MUC room?
Related
From the spec —
7.14 Exiting a Room
In order to exit a multi-user chat room, an occupant sends a presence
stanza of type "unavailable" to the <room#service/nick> it is
currently using in the room.
Example 80. Occupant Exits a Room
<presence
from='hag66#shakespeare.lit/pda'
to='coven#chat.shakespeare.lit/thirdwitch'
type='unavailable'/>
This implies that as soon as the user disconnects from the XMPP server, he is removed from the group on the server side. The issue is simple — I don't want this behavior; I want a behavior that is similar to what Whatsapp does, i.e. even if the user goes offline, he is still part of the MUC room (which is configured to be persistent on the server side) and will receive messages from other occupants.
Given the spec and the documentation for XEP-0045 and XMPPFramework for iOS, I have no idea how to accomplish this or if it's possible to accomplish this in the traditional ejabberd server.
XEP-45 was designed more then 10 years ago. Back then, the designers had something like IRC channels in mind. Everything of XEP-45 is designed based on the assumption that a user enters and leaves a room when he/she starts/terminates its client.
WhatsApp Groupchats are different: A user joins a groupchat is is able to view the (complete) history of that chat. Even if the users client is offline/unavailable, he is still considered part of the groupchat.
The XMPP community currently works on a new XEP that provides such functionality. It is called XEP-0369: Mediated Information eXchange. It is the spiritual successor of XEP-0045, providing the features one would expect from modern groupchats.
You could emulate something quite like this by using server-side history of the MUC (Message Archive Management, XEP-0313), so that when a client logs in they're able to request the history of the MUC while they weren't in it.
If you also want to be able to show the offline pseudo-occupants of a room, the easiest way to do this is probably to map a pubsub node per room to store the list of these pseudo-occupants that clients could read to supplement the usual occupancy list.
There are probably other solutions here, but those that come immediately to mind for me involve changing the behaviour of the server in non-standard ways, such as allowing normal occupants to query a membership list, which normally only admins can do.
The Whatsapp model is much simpler than you imagine - they just maintain user session online even if user disconnects, and re-sends messages when he "reattach" session. XEP-0198 introduce similar concept to traditional XMPP sessions. You only need to configure longer inactivity period (typically XEP-0198 assume 300 seconds, but whatsapp-like messengers holds session 24+ hours)
Yes you can make your group persistent by setting its configurations this way:
NSString *var = [field attributeStringValueForName:#"var"];
if ([var isEqualToString:#"muc#roomconfig_persistentroom"])
{
[field removeChildAtIndex:0];
[field addChild:[NSXMLElement elementWithName:#"value" stringValue:#"1"]];
}
When we connect to googletalk using xmpp, we can set the resource attribute, and can thus identify whether the user is logged in from android, pc etc.
I was wondering if there is any similar way to specify/identify device in facebook chat API.
When I connect with xmpp, facebook do all the internal transation and erase off my resource value.
Is there any other way to achieve this?
This is not what the resource identifier is meant for, even if many users or software put human readable text there. For security reason the resource should be unpredictable.
Use Service Discovery:
http://xmpp.org/extensions/xep-0030.html
Use XEP-0115: Entity Capabilities. Mark up your presence stanzas with caps. Pre-load the caps cache of all of your clients with the disco#info describing each. This will just barely work for your clients on FaceBook, and will interoperate really well on other systems.
Please read the XEP multiple times. Almost everyone misunderstands it at first.
I'm using XMPP to drive a notification system. Basically I will have a set of services, some of which will broadcast to all users and some which are directed to a specific client (full JID).
For a service that broadcasts to all users a PubSub node seems the obvious choice but for a service that targets its messages to a specific client, I'm unsure of the best mechanism to use.
Do I represent these services as other client users and create bespoke implementations for them? The problem I see with this is how will they be discovered? Do I group them into a chat room and discover that. It feels like a bit of a hack. I could also define my own bespoke type of service, but then I have to define my own XML tags and maintain that.
I know there are plenty of standard extensions to XMPP but I cant see anything useful in this case.
Even in the pubsub case, the publisher (i.e. your service) is still a "user", so this configuration will be pretty standard. We simply create service accounts to represent those "users".
I am unsure of what you mean by "how will they be discovered". Why do the services need to be discovered? Your scenario only gives the use case of services sending messages to the users. Assuming the service already knows who the message is to be sent to, then you don't need any other information to send a message.
I know that user agent can be faked easily when connecting through HTTP. I want to ensure access to my SOAP API only from iPhone devices. We don't know how many users will be using this when it is released but it might be a lot and we can't handle traffic from outside of the devices. Any other means to prevent this?
It's not clear to me why limiting just to iPhones would be the way to go since I guess what you're really worried about is volume per user on the API (iPhone or not) and number of users. Spoofing the client is pretty easy so a better way to would be either to issue keys/ids on signup and then limit volume on each key or by IP address. Using keys also means you'll have a better ID on your users which might be useful in the long run. IP addresses could be problematic with mobile clients but at least you can do some basic load limiting.
Unless you control both sides, there's no way to determine the type of the other party reliably over HTTP.
No. (Outside of asking them if they're on an iPhone of course.)
Beside the obvious person to person instant message chat, What else have you used a Jabber server's functionality to enable?
Edit: links to working code to really show it off are particularly useful - and will be more likely to be voted up.
There are unlimited uses for XMPP/Jabber.
Take any message/data you want to send somewhere else and you can use jabber. Run a centralised logging service for distributed services? You can jabber the massage.
You want to check if your services/programs are running? XMPP presence will tell you. If you add custom status messages you can see exactly what is going on.
This is why Cisco has got into the game. Picture a server farm where each blade has a built in mini jabber client. On boot up it will register it's presence to the central server as awaiting work. The central server fires off some work in it's direction and it then changes it's status to "Busy". Another blade finished it's work and changes it's status back to "Available"... rinse and repeat.
When you combine the actual jabber messages with it's Out Of Band abilities, these servers can post where the results of the job can be found.
Anything you can think of needing to pass a message can be done with XMPP to some degree. Be this person to person, program to program, or any combination.
You could use a Jabber server to handle/broker messages between a client application and another server application.
It can actually be pretty effective.
Not me but Martin Woodward used jabber to control a "build bunny" that displays the current status of the build server.
http://www.woodwardweb.com/gadgets/000434.html
XMPP is good for sending messages back and forth between computers that don't need to be broken into chunks. They also can't be terribly big. If you use the right library, it can be pretty easy to set up.
Sending messages to a web page. Proof-of-concept: esagila.com
I plan to use it to receive notifications from my system, such as:
Process did not finish
Report was not generated on time
User needs help
I already receive many of these messages as email. But receiving an IM could be much more effective.
You might want to look at Vertebra which is...
a framework for orchestrating complex processes in a Cloud. It is designed with an emphasis on security, fault tolerance, and portability.
From the knowledge base:
Why was XMPP chosen for Vertebra?
XMPP based instant messaging can be a good alternative to search engines for information that is small, complete in itself and required frequently and repeatedly. For example, your daily horoscope - you require it daily and it is not large.
To see an example of this add astro#askme.im to your list of contacts in your jabber client (Gmail Chat/Gtalk/or any other Jabber client) and then initiate chat with this contact by sending the word "help".
Also see www.askme.im for a whole list of chat based solutions.
I've used Jabber in the past to get email notifications. Nowadays I use it for low-priority nagios notifications, it is very useful and way cheaper than SMS:
We use xmpp as both a 'bus' and a real-time API at http://superfeedr.com
Iowa State University Department of Agronomy has created this with Jabber: http://mesonet.agron.iastate.edu/iembot/
If you're a weather freak like I am, this is VERY cool stuff!
Apple implements mobileme's push service using Jabber/XMPP's subscription services to send push notifications. That is the most widespread use of Jabber for non-IM purposes I know of. This article has more details.
My friends have also built a Jabber python bot, which is kinda cute but not all that useful :-)
Edit
The most recent Next Big Thing, Google Wave, uses Jabber under the hood. Further illustrates the power of the protcol.
We have used XMPP and BOSH to enable users to communicate with a webbrowser directly and in realtime from their phone.
For example Code you can view our open source API
The vooices site also has live examples where you can control a map and play a game using your phone via your web browser: http://www.vooices.us/
I've always thought XMPP would be a good way to deliver SNMP data. OIDs are really painful, much of the system is insecure, and the SNMP traps never work quite like you want them to. With an XMPP server in the middle and a smart component to make some choices, you can use it to send out jabber or other notifications, kick off restart jobs, update web pages, or whatever else you need.
The XML data is pretty small in this case, and you can have the one XMPP server both talk to humans in message stanzas, or computers with the same protocol.