sum7/Conversations
sum7
/
Conversations
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix spelling in the docs 

Also rewrap at 80 chars (which looked to be what it was at in most
places)
This commit is contained in:
Sam Whited 2014-12-28 19:48:01 -05:00
parent 193d2645e6
commit 5a8391b539
2 changed files with 49 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
docs/MISSION.md
View File

@ -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.

58
docs/obeservations.md
View File

@ -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