<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Xmpp on Puppeteers Oy</title>
		<link>https://www.puppeteers.net/tags/xmpp/</link>
		<description>Recent content in Xmpp on Puppeteers Oy</description>
		<generator>Hugo</generator>
		<language>en-US</language>
		
		
		
		
			<lastBuildDate>Fri, 12 Feb 2021 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://www.puppeteers.net/tags/xmpp/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Configuring ejabberd multi-user chatrooms</title>
				<link>https://www.puppeteers.net/blog/configuring-ejabberd-multi-user-chatrooms/</link>
				<pubDate>Fri, 12 Feb 2021 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/configuring-ejabberd-multi-user-chatrooms/</guid>
				<description>&lt;p&gt;&lt;a href=&#34;https://www.ejabberd.im/&#34;&gt;Ejabberd&lt;/a&gt; is a very flexible and scalable XMPP server. We use it because it can be configured using a simple yaml configuration file and managed via &lt;em&gt;ejabberdctl&lt;/em&gt; commands. This makes it a good fit for our infrastructure as code approach. That said, ejabberd does require one to understand the XMPP protocol/jargon as it does not abstract away any of it. So simple things like creating chatrooms, limiting access to them and playing history backlog to users who connected them can be an effort if you&amp;rsquo;ve never done it.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Ejabberd message archiving and history playback</title>
				<link>https://www.puppeteers.net/blog/ejabberd-message-archiving-and-history-playback/</link>
				<pubDate>Fri, 12 Feb 2021 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/ejabberd-message-archiving-and-history-playback/</guid>
				<description>&lt;p&gt;When using &lt;a href=&#34;https://www.ejabberd.im/&#34;&gt;ejabberd&lt;/a&gt; in a company for multi-user chat (see &lt;a href=&#34;https://www.puppeteers.net/blog/configuring-ejabberd-multi-user-chatrooms/&#34;&gt;my earlier blog post&lt;/a&gt;) people will quickly start complaining that they missed discussions because they had been offline. Ejabberd &lt;em&gt;does&lt;/em&gt; play back last 20 messages when user joins a room, but that is too little for an active chatroom. The simplistic approach is to set &lt;em&gt;history_size&lt;/em&gt; in &lt;a href=&#34;https://docs.ejabberd.im/archive/20_04/modules/#mod-muc&#34;&gt;mod_muc settings&lt;/a&gt; in ejabberd.yml to a higher value:&lt;/p&gt;&#xA;&lt;div class=&#34;code-block&#34;&gt;&#xA;    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;&#xA;      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;&#xA;    &lt;/button&gt;&#xA;    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;mod_muc:&#xA;  history_size: 200&#xA;  --- snip ---&lt;/code&gt;&lt;/pre&gt;&#xA;  &lt;/div&gt;&lt;p&gt;This simplistic approach should work with any XMPP clients.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Testing connection recovery with ss</title>
				<link>https://www.puppeteers.net/blog/testing-connection-recovery-with-ss/</link>
				<pubDate>Sat, 30 May 2020 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/testing-connection-recovery-with-ss/</guid>
				<description>&lt;p&gt;As mentioned in our &lt;a href=&#34;https://www.puppeteers.net/blog/email-to-xmpp-bridge-milter-xmpp-released/&#34;&gt;earlier blog post&lt;/a&gt; we created an &amp;ldquo;email to XMPP bridge&amp;rdquo; called &lt;a href=&#34;https://github.com/Puppet-Finland/milter-xmpp/&#34;&gt;milter-xmpp&lt;/a&gt; for forwarding alert emails from monitoring systems to an XMPP chatroom. It was known that if the connection to the XMPP server ever died the bridge would stop working, but we wanted to know how fast that would happen. It took some days, but eventually the connection died.&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://github.com/Puppet-Finland/milter-xmpp/commit/753381339cb4a750e758a33a61c0050236fc0297&#34;&gt;fix&lt;/a&gt; ended up being quite trivial, but we needed a way to break the connection. Fortunately the good folks at StackExchange already &lt;a href=&#34;https://unix.stackexchange.com/questions/71940/killing-tcp-connection-in-linux&#34;&gt;had a good solution&lt;/a&gt;: use the &amp;ldquo;ss&amp;rdquo; tool (&amp;ldquo;another utility to investigate sockets&amp;rdquo;) which provides output similar to netstat:&lt;/p&gt;</description>
			</item>
			<item>
				<title>Email to XMPP bridge &#34;milter-xmpp&#34; released</title>
				<link>https://www.puppeteers.net/blog/email-to-xmpp-bridge-milter-xmpp-released/</link>
				<pubDate>Tue, 26 May 2020 00:00:00 +0000</pubDate>
				<guid>https://www.puppeteers.net/blog/email-to-xmpp-bridge-milter-xmpp-released/</guid>
				<description>&lt;p&gt;We have used &lt;a href=&#34;https://en.wikipedia.org/wiki/XMPP&#34;&gt;XMPP&lt;/a&gt; (Jabber) for our internal discussions for years. In the recent years it &lt;em&gt;seems&lt;/em&gt; that XMPP has lost some of its traction. For example, Google and Facebook used to use XMPP for instant message and Slack used to have an XMPP bridge in their service. All of those are now gone and have been replaced with proprietary messaging protocols. In the context of a big company having all the control over the protocol probably makes sense, but it of course makes life difficult for users who have to have a separate client for each or have to use a multi-protocol client such &lt;a href=&#34;https://pidgin.im/&#34;&gt;Pidgin&lt;/a&gt; just to keep their sanity. And none of the big players seems to &amp;ldquo;winning the war&amp;rdquo; for users.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
