Hi,
Some pre-meeting ideas where sent to the mailing list:
* http://mail.jabber.org/pipermail/operators/2009-May/000584.html
* http://mail.jabber.org/pipermail/operators/2009-June/000601.html
1. Radar
The idea of having a site that lists domains that have a XMPP
service,
and associated stats
(Ed: during the discussion the notion of radar and monitoring service
seemed to merge, not sure if it should merge)
Domains could be added by anybody or by any means to the radar DB,
the
information collected is publicly available on a web site.
Mickael is worried about spam, if the database is available
publicly or
if the service allows listing of domains. The issue of database
ownership was raised but not discussed.
Current consensus is:
* collect information from all domains found: how to find new domains
was not discussed though;
* publish information on the radar site, but allow for opt-out:
methods
for opt-out where not discussed.
=> Possible next steps:
* gather suggestions about how to collect new domains;
* methods to opt-out.
The radar should have some way to include information (description,
URLs, logo) in the domain/service page. There where some discussion
on
how to do this, the consensus seems to be that a pubsub node @domain
with a well known node would work. A IQ based fallback was also
mentioned.
=> Possible next steps:
* specify types of payload: Articles (atom entries?) and "vcard"
for the
domain (meta data like contact address, URL, description) were
mentioned
as possible payloads.
A second method for radar metadata maintenance was discussed:
domain/service ops should be able to use a HTML form at the radar
site
to update the information.
The admins could authorize themselves to the radar web interface
with a
simple token sent with a <message> to the domain/service. After that,
the ops can use the radar web interface to publish announcements,
updates and other tweaks. Useful for downtimes.
A protocol using <presence> of the x...@domain jid to update the
status
of the domain/service was mentioned as a simple alternative to keep
server status flowing.
There where some discussion about what is federation and if we can
connect to the s2s port uninvited just because you have S2S DNS
records.
No clear consensus.
Current Radar examples:
* http://imtrends.com/
*
http://74.125.155.132/search?q=cache:VuFw301LIFUJ:www.jabberes.org/servers/%3Fsort%3Dhas_pep%26order%3Ddesc+jabberes+list&cd=2&hl=en&ct=clnk&gl=us
* http://coccinella.im/servers/servers.html
* http://coccinella.im/servers/servers_by_pubsub_pep.html
2. Domain for the radar
Several proposals:
* radar.xmpp.net;
* xmpp-services.org;
* monitor.im;
* up.im;
* imradar.com / imradar.org (Ed: it seems that monitor and radar
are the
same project? I don't think they are.);
* uptime.im.
3. Monitoring
A service to monitor servers uptime was also discussed. Tobias is
working on something like that. His current interface is at
http://monitor.ayena.de.
The consensus seems to be that the monitoring should be done
distributed, and reports would be send to a collector agent that
would
correlate the information.
Some (stpeter, melo) would like to see the Server Roster XEP used for
monitoring, for example, having each server monitor all the servers
in
his roster.
Some domains where suggested to host this service:
* yourstatus.org;
* viewstatus.org;
* whatsup.im;
* bigbrother.im;
=> Possible next actions:
* ??;
4. Robots
robots.txt for xmpp: a version of the HTTP ad-hoc protocol for
crawler
control was discussed.
Several options for implementation - a new <feature> in disco#info.
The
robots.txt file would be available with a iq-based protocol or on a
well
known pubsub node on the server. the server vcard was also
mentioned as
a possible place for this
no further talk about what this robots.txt would contain. It was
suggested to use the same format as HTTP but no discussion about if
that
is appropriate or workable....
=> Possible next actions:
* define a "robots.txt" format for XMPP use;
5. Domain admins
The topic of which JIDs should be accepted as domain admins was
present
through out the conversation. The x...@domain and ow...@domain
hard-coded addresses where noted, as was XEP-0157.
A disco#items method for discovering admin JIDs (using a well-known
node
value like 'urn:xmpp:valid-admins' for example) was also floated.
Using
a well known pubsub node @domain was also presented as an
alternative.
There was no clear consensus but several people (Mickael, bear, melo)
prefered a pubsub-based approach.
6. Other topics
A brave attempt by JMcA to bring the subject of a standard server
configuration file format to ease the pain of switching servers.
Best regards,
