Merge pull request #819 from SamWhited/spelling
Fix spelling in the docs / a method
This commit is contained in:
commit
35d9e3fe4a
|
@ -1,25 +1,25 @@
|
||||||
Conversations is a messenger for the next decade. Based on already established
|
Conversations is a messenger for the next decade. Based on already established
|
||||||
internet standards that have been around for over ten years Coversations isn’t
|
internet standards that have been around for over ten years Conversations isn’t
|
||||||
trying to replace current commercial messengers. It will simply outlive them.
|
trying to replace current commercial messengers. It will simply outlive them.
|
||||||
Commercial, closed source products are coming and going. 15 years ago we had
|
Commercial, closed source products are coming and going. 15 years ago we had ICQ
|
||||||
ICQ which was replaced by Skype. MySpace was replaced by Facebook. WhatsApp and
|
which was replaced by Skype. MySpace was replaced by Facebook. WhatsApp and
|
||||||
Hangouts will disapear soon. Internet standards however stick around. People are
|
Hangouts will disappear soon. Internet standards however stick around. People
|
||||||
still using IRC and e-mail even though these protocols have been around for
|
are still using IRC and e-mail even though these protocols have been around for
|
||||||
decades. Utilizing proven standards doesn’t mean one can not evolve. GMail has
|
decades. Utilizing proven standards doesn’t mean one can not evolve. GMail has
|
||||||
revolutionized the way we look at e-mail. Firefox and Chrome have changed the
|
revolutionized the way we look at e-mail. Firefox and Chrome have changed the
|
||||||
way we use the Web. Conversations will change the way we look at instant
|
way we use the Web. Conversations will change the way we look at instant
|
||||||
messaging. Being less obstrusive than a telephone call instant messaging has
|
messaging. Being less obtrusive than a telephone call instant messaging has
|
||||||
always played an importent role in modern society. Conversations will show that
|
always played an important role in modern society. Conversations will show that
|
||||||
instant messaging can be fast, relialbe and private. Conversations will not
|
instant messaging can be fast, reliable and private. Conversations will not
|
||||||
force its security and privacey aspects upon the user. For those willing to use encryption
|
force its security and privacy aspects upon the user. For those willing to use
|
||||||
Conversations will make it as uncomplicated as possible. However Conversations
|
encryption Conversations will make it as uncomplicated as possible. However
|
||||||
is aware that end-to-end encryption by the very principle isn’t trivial. Instead
|
Conversations is aware that end-to-end encryption by the very principle isn’t
|
||||||
of trying the impossible and making encryption easier than comparing a
|
trivial. Instead of trying the impossible and making encryption easier than
|
||||||
fingerprint Conversations will try to educate the willing user and explain the
|
comparing a fingerprint Conversations will try to educate the willing user and
|
||||||
necessary steps and the reasons behind them. Those unwilling to learn about
|
explain the necessary steps and the reasons behind them. Those unwilling to
|
||||||
encryption will still be protected by the design principals of Conversations.
|
learn about encryption will still be protected by the design principals of
|
||||||
Conversations will simply not share or generate certain information for example
|
Conversations. Conversations will simply not share or generate certain
|
||||||
by encouraging the use of federated servers. Conversations will always
|
information for example by encouraging the use of federated servers.
|
||||||
utilize the best available standards for encryption and media encoding instead
|
Conversations will always utilize the best available standards for encryption
|
||||||
of reinventing the wheel. However it isn’t afraid to break with behavior patterns
|
and media encoding instead of reinventing the wheel. However it isn’t afraid to
|
||||||
that have been proven ineffctive.
|
break with behavior patterns that have been proven ineffective.
|
||||||
|
|
|
@ -2,7 +2,7 @@ Observations on implementing XMPP
|
||||||
=================================
|
=================================
|
||||||
After spending the last two and a half month basically writing my own XMPP
|
After spending the last two and a half month basically writing my own XMPP
|
||||||
library from scratch I decided to share some of the observations I made in the
|
library from scratch I decided to share some of the observations I made in the
|
||||||
process.. In part this article can be seen as a response to a blog post made by
|
process. In part this article can be seen as a response to a blog post made by
|
||||||
Dr. Ing. Georg Lukas. The blog post introduces a couple of XEP (XMPP Extensions)
|
Dr. Ing. Georg Lukas. The blog post introduces a couple of XEP (XMPP Extensions)
|
||||||
which make the life on mobile devices a lot easier but states that they are
|
which make the life on mobile devices a lot easier but states that they are
|
||||||
currently very few implementations of those XEPs. So I went ahead and
|
currently very few implementations of those XEPs. So I went ahead and
|
||||||
|
@ -19,27 +19,27 @@ and straight forward. But then came the XEPs.
|
||||||
###Multi-User Chat
|
###Multi-User Chat
|
||||||
The first one was XEP-0045 Multi-User Chat. This is the one XEP of the XEPs I’m
|
The first one was XEP-0045 Multi-User Chat. This is the one XEP of the XEPs I’m
|
||||||
going to mention in my article which is actually wildly adopted. Most clients
|
going to mention in my article which is actually wildly adopted. Most clients
|
||||||
and servers I know of support MUC. However the level of completeness varies.
|
and servers I know of support MUC. However the level of completeness varies.
|
||||||
MUC actually introduces access and permission roles which are far more complex
|
MUC actually introduces access and permission roles which are far more complex
|
||||||
than what some of us are used to from IRC but a lot of clients just don’t
|
than what some of us are used to from IRC but a lot of clients just don’t
|
||||||
implement them. I’m not implementing them myself (at least for now) because I
|
implement them. I’m not implementing them myself (at least for now) because I
|
||||||
somewhat doubt that someone would actually use them. (How ever this might be
|
somewhat doubt that someone would actually use them (however this might be some
|
||||||
some sort of chicken or egg problem.) I did find some strange bugs though which
|
sort of chicken or egg problem). I did find some strange bugs though which might
|
||||||
might be interesting for other library developers. In theory a MUC server
|
be interesting for other library developers. In theory a MUC server
|
||||||
implementation can allow a single user (same jid) to join a conference room
|
implementation can allow a single user (same jid) to join a conference room
|
||||||
multiple times with the same nick from different clients. This means if someone
|
multiple times with the same nick from different clients. This means if someone
|
||||||
wants to participate in a conference from two different devices (mobile and
|
wants to participate in a conference from two different devices (mobile and
|
||||||
desktop for example) one wouldn’t have to name oneself userDesktop and
|
desktop for example) one wouldn’t have to name oneself `userDesktop` and
|
||||||
userMobile but just user. Both ejabberd and prosody support this but with
|
`userMobile` but just `user`. Both ejabberd and prosody support this but with
|
||||||
strange side effects. prosody for example doesn’t allow a user to change its
|
strange side effects. Prosody for example doesn’t allow a user to change its
|
||||||
name once two clients are “merged” by having the same nick.
|
name once two clients are “merged” by having the same nick.
|
||||||
|
|
||||||
###Carbons and Stream Management
|
###Carbons and Stream Management
|
||||||
Two of the other XEPs Lukas’ mentions - Carbons (XEP-0280) and Stream Management
|
Two of the other XEPs Lukas mentions — Carbons (XEP-0280) and Stream Management
|
||||||
(XEP-0198) - were actually fairly easy to implement. The only challenges were to
|
(XEP-0198) — were actually fairly easy to implement. The only challenges were to
|
||||||
find a server to support them (I ended up running my own prosody server) and a
|
find a server to support them (I ended up running my own Prosody server) and a
|
||||||
desktop client to test them with. For carbons there is a patched mcabber version
|
desktop client to test them with. For carbons there is a patched Mcabber version
|
||||||
and gajim. After implementing stream management I had very good results on my
|
and Gajim. After implementing stream management I had very good results on my
|
||||||
mobile device. I had sessions running for up to 24 hours with a walking outside,
|
mobile device. I had sessions running for up to 24 hours with a walking outside,
|
||||||
loosing mobile coverage for a few minutes and so on. The only limitation was
|
loosing mobile coverage for a few minutes and so on. The only limitation was
|
||||||
that I had to keep on developing and reinstalling my app.
|
that I had to keep on developing and reinstalling my app.
|
||||||
|
@ -52,14 +52,14 @@ come to some sort of consent among XMPP developers to ultimately increase the
|
||||||
interoperability. OTR has some down sides which make it difficult or at times
|
interoperability. OTR has some down sides which make it difficult or at times
|
||||||
even dangerous to implement within XMPP. First of all it is a synchronous
|
even dangerous to implement within XMPP. First of all it is a synchronous
|
||||||
protocol which is tunneled through a different protocol (XMPP). Synchronous
|
protocol which is tunneled through a different protocol (XMPP). Synchronous
|
||||||
means - among other things - auto replies. (An OTR session begins with “hi I’m
|
means — among other things — auto replies. (An OTR session begins with “hi I’m
|
||||||
speaking otr give me your key” “ok cool here is my key”) And auto replies - we
|
speaking otr give me your key” “ok cool here is my key”) And auto replies — we
|
||||||
know that since the first time an out of office auto responder went postal - are
|
know that since the first time an out of office auto responder went postal — are
|
||||||
dangerous. Things really start to get messy when you use one of the best
|
dangerous. Things really start to get messy when you use one of the best
|
||||||
features of XMPP - multiple clients. The way XMPP works is that clients are
|
features of XMPP — multiple clients. The way XMPP works is that clients are
|
||||||
encouraged to send their messages to the raw jid and let the server decide what
|
encouraged to send their messages to the raw jid and let the server decide what
|
||||||
full jid the messages are routed to. If in doubt even all of them. So what
|
full jid the messages are routed to. If in doubt even all of them. So what
|
||||||
happens when Alice sends a start-otr-message to Bobs raw jid? Bob receives the
|
happens when Alice sends a start-otr-message to Bobs raw jid? Bob receives the
|
||||||
message on his notebook as well as his cell phone. Both of them answer. Alice
|
message on his notebook as well as his cell phone. Both of them answer. Alice
|
||||||
gets two different replies. Shit explodes. Even if Alice sends the message to
|
gets two different replies. Shit explodes. Even if Alice sends the message to
|
||||||
bob/notebook chances are that Bob has carbon messages enabled and still receives
|
bob/notebook chances are that Bob has carbon messages enabled and still receives
|
||||||
|
@ -67,11 +67,11 @@ the messages on both devices. Now assuming that Bobs client is clever enough not
|
||||||
to auto reply to carbonated messages Bob/cellphone will still end up with a lot
|
to auto reply to carbonated messages Bob/cellphone will still end up with a lot
|
||||||
of garbage messages. (Essentially the entire conversation between Alice and
|
of garbage messages. (Essentially the entire conversation between Alice and
|
||||||
Bob/notebook but unreadable of course) Therefor it should be good practice to
|
Bob/notebook but unreadable of course) Therefor it should be good practice to
|
||||||
tag OTR messages as both private and no-copy. (private is part of the carbons
|
tag OTR messages as both private and no-copy (private is part of the carbons
|
||||||
XEP, no-copy is a general hint. I found that prosody for some reasons doesn’t
|
XEP, no-copy is a general hint). I found that prosody for some reasons doesn’t
|
||||||
honor the private tag on outgoing messages. While this is easily fixed I presume
|
honor the private tag on outgoing messages. While this is easily fixed I presume
|
||||||
that having both the private and the no-copy tag will make it more compatible
|
that having both the private and the no-copy tag will make it more compatible
|
||||||
with servers or clients I don’t know about yet)
|
with servers or clients I don’t know about yet.
|
||||||
|
|
||||||
####Rules to follow when implementing OTR
|
####Rules to follow when implementing OTR
|
||||||
To summarize my observations on implementing OTR in XMPP let me make the
|
To summarize my observations on implementing OTR in XMPP let me make the
|
||||||
|
@ -81,17 +81,17 @@ following three statements.
|
||||||
and have the receiving server or user decide how they should be routed OTR
|
and have the receiving server or user decide how they should be routed OTR
|
||||||
messages must be send to a specific resource. To make this work the user should
|
messages must be send to a specific resource. To make this work the user should
|
||||||
be given the option to select the presence (which can be assisted with some
|
be given the option to select the presence (which can be assisted with some
|
||||||
educated guessing by the client based on previous messages).
|
educated guessing by the client based on previous messages). Furthermore a
|
||||||
Furthermore a client should encourage a user to choose meaningful presences
|
client should encourage a user to choose meaningful presences instead of the
|
||||||
instead of the clients name or even random ones. Something like /mobile,
|
clients name or even random ones. Something like `/mobile`, `/notebook`,
|
||||||
/notebook, /desktop is a greater assist to any one who wants to start an otr
|
`/desktop` is a greater assist to any one who wants to start an otr session then
|
||||||
session then /Gajim, /mcabber or /pidgin
|
`/Gajim`, `/mcabber` or `/pidgin`.
|
||||||
|
|
||||||
2. Messages should be tagged private and no-copy to avoid unnecessary traffic or
|
2. Messages should be tagged private and no-copy to avoid unnecessary traffic or
|
||||||
otr error loops with faulty clients. This tagging should be done even if your
|
otr error loops with faulty clients. This tagging should be done even if your
|
||||||
own client doesn’t support carbons.
|
own client doesn’t support carbons.
|
||||||
|
|
||||||
3. When dealing with “legacy clients” - meaning clients which don’t follow my
|
3. When dealing with “legacy clients” — meaning clients which don’t follow my
|
||||||
advise a client should be extra careful not to create message loops. This means
|
advise — a client should be extra careful not to create message loops. This
|
||||||
to not respond with otr errors if a client is not 100% sure it is the only
|
means to not respond with otr errors if a client is not 100% sure it is the only
|
||||||
client which received the message
|
client which received the message
|
|
@ -141,12 +141,12 @@ public class IqParser extends AbstractParser implements OnIqPacketReceived {
|
||||||
.discoResponse(packet);
|
.discoResponse(packet);
|
||||||
account.getXmppConnection().sendIqPacket(response, null);
|
account.getXmppConnection().sendIqPacket(response, null);
|
||||||
} else if (packet.hasChild("ping", "urn:xmpp:ping")) {
|
} else if (packet.hasChild("ping", "urn:xmpp:ping")) {
|
||||||
final IqPacket response = packet.generateRespone(IqPacket.TYPE_RESULT);
|
final IqPacket response = packet.generateResponse(IqPacket.TYPE_RESULT);
|
||||||
mXmppConnectionService.sendIqPacket(account, response, null);
|
mXmppConnectionService.sendIqPacket(account, response, null);
|
||||||
} else {
|
} else {
|
||||||
if ((packet.getType() == IqPacket.TYPE_GET)
|
if ((packet.getType() == IqPacket.TYPE_GET)
|
||||||
|| (packet.getType() == IqPacket.TYPE_SET)) {
|
|| (packet.getType() == IqPacket.TYPE_SET)) {
|
||||||
final IqPacket response = packet.generateRespone(IqPacket.TYPE_ERROR);
|
final IqPacket response = packet.generateResponse(IqPacket.TYPE_ERROR);
|
||||||
final Element error = response.addChild("error");
|
final Element error = response.addChild("error");
|
||||||
error.setAttribute("type", "cancel");
|
error.setAttribute("type", "cancel");
|
||||||
error.addChild("feature-not-implemented",
|
error.addChild("feature-not-implemented",
|
||||||
|
|
|
@ -191,10 +191,10 @@ public class JingleConnection implements Downloadable {
|
||||||
}
|
}
|
||||||
IqPacket response;
|
IqPacket response;
|
||||||
if (returnResult) {
|
if (returnResult) {
|
||||||
response = packet.generateRespone(IqPacket.TYPE_RESULT);
|
response = packet.generateResponse(IqPacket.TYPE_RESULT);
|
||||||
|
|
||||||
} else {
|
} else {
|
||||||
response = packet.generateRespone(IqPacket.TYPE_ERROR);
|
response = packet.generateResponse(IqPacket.TYPE_ERROR);
|
||||||
}
|
}
|
||||||
account.getXmppConnection().sendIqPacket(response, null);
|
account.getXmppConnection().sendIqPacket(response, null);
|
||||||
}
|
}
|
||||||
|
|
|
@ -46,7 +46,7 @@ public class JingleConnectionManager extends AbstractConnectionManager {
|
||||||
return;
|
return;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
IqPacket response = packet.generateRespone(IqPacket.TYPE_ERROR);
|
IqPacket response = packet.generateResponse(IqPacket.TYPE_ERROR);
|
||||||
Element error = response.addChild("error");
|
Element error = response.addChild("error");
|
||||||
error.setAttribute("type", "cancel");
|
error.setAttribute("type", "cancel");
|
||||||
error.addChild("item-not-found",
|
error.addChild("item-not-found",
|
||||||
|
|
|
@ -208,15 +208,15 @@ public class JingleInbandTransport extends JingleTransport {
|
||||||
established = true;
|
established = true;
|
||||||
connected = true;
|
connected = true;
|
||||||
this.account.getXmppConnection().sendIqPacket(
|
this.account.getXmppConnection().sendIqPacket(
|
||||||
packet.generateRespone(IqPacket.TYPE_RESULT), null);
|
packet.generateResponse(IqPacket.TYPE_RESULT), null);
|
||||||
} else {
|
} else {
|
||||||
this.account.getXmppConnection().sendIqPacket(
|
this.account.getXmppConnection().sendIqPacket(
|
||||||
packet.generateRespone(IqPacket.TYPE_ERROR), null);
|
packet.generateResponse(IqPacket.TYPE_ERROR), null);
|
||||||
}
|
}
|
||||||
} else if (connected && payload.getName().equals("data")) {
|
} else if (connected && payload.getName().equals("data")) {
|
||||||
this.receiveNextBlock(payload.getContent());
|
this.receiveNextBlock(payload.getContent());
|
||||||
this.account.getXmppConnection().sendIqPacket(
|
this.account.getXmppConnection().sendIqPacket(
|
||||||
packet.generateRespone(IqPacket.TYPE_RESULT), null);
|
packet.generateResponse(IqPacket.TYPE_RESULT), null);
|
||||||
} else {
|
} else {
|
||||||
// TODO some sort of exception
|
// TODO some sort of exception
|
||||||
}
|
}
|
||||||
|
|
|
@ -67,7 +67,7 @@ public class IqPacket extends AbstractStanza {
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
public IqPacket generateRespone(final int type) {
|
public IqPacket generateResponse(final int type) {
|
||||||
final IqPacket packet = new IqPacket(type);
|
final IqPacket packet = new IqPacket(type);
|
||||||
packet.setTo(this.getFrom());
|
packet.setTo(this.getFrom());
|
||||||
packet.setId(this.getId());
|
packet.setId(this.getId());
|
||||||
|
|
Loading…
Reference in New Issue