Project Proposals

From XMPP WIKI
Revision as of 02:21, 17 December 2020 by Neustradamus (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page is intended to be a repository of ideas for XMPP-related projects.

Servers

  • A framework for migrating server data. For example, with an ejabberd and a Wildfire plugin, one could easily migrate the data from one server to the other. (Remko)
  • A lightweight XMPP daemon that acts as a regular XMPP server on the client side, but uses Serverless Messaging on the server side. Running this daemon on a local machine allows any XMPP clients to support link local messaging by connecting to the daemon on localhost. (Remko)
  • A "Server Discovery" feature in each client, so that a never-have-used-XMPP-before user can download/install/launch an XMPP client and create an account from within his software, without having to search the web and ask in forums "what server do I have to use?". (Nyco)
  • Distributed monitoring of the Jabber network (was Distributed monitoring of the Jabber network)
  • A system working somewhat like rooms, with forever-logged messages, and presence too: those "rooms" would be used for meetings. They would have three user lists, a date+time field, a location (real or virtual), a topic big enough to contain a small description of the program of the meeting, and a public area where users would post comments ("great, i'll be there!", "sorry people, i'm ill", ...). The three user lists limit could be extended, but actually the idea is: one list for participants, one for one's that have refused the invitation, and one for the "not sure" ones. The extension would allow the meeting manager to define more categories in which subdivide the users; the categories could be thinked as just "flags" in front of each user, instead of those big userlist boxes. A post-meeting photo-album system could be nice, too (asking too much, eh? ;).
  • A option that the server could publish its registered users and group them. Even to show the online-status would be great.
  • Use of tags to group members. This is esp. for comercial use where buddylists arn't sufficient.