App-Entwicklung: Whatsapp-Alternative
lima-city → Forum → Heim-PC → Software
akku
ansatz
code
datei
datum
entwickler
entwicklung
frage
idee
nachricht
nachteil
nutzen
problem
projekt
server
service
telefonnummer
url
verwenden
windows
-
Leute, Leute, Leute ...
Dateien werden doch nicht in Text umgewandelt. :D Jabber bietet von Haus aus die Möglichkeit, Dateien zu versenden. Ihr könnt ja mal eure Lima-Jabber-Adresse nutzen und das ausprobieren. ;)
Beim Akku sehe ich momentan aber auch das größte Problem, es macht aber keinen Sinn, jetzt schon zu optimieren. Erst mal muss das Grundgerüst stehen:
Kontakt kann mit Kontakt schreiben.
Danach kann man paralel an diesen Dingen arbeiten:
Konferenzen (welche nicht verschlüsselt werden können, leider)
Dateien versenden
OTR (Verschlüsselung) integrieren
Dann kümmert man sich um Feinheiten wie die Akkuleistung und ein schönes UI etc pp.
Btw: Whatsapp nutzt Jabber und schafft es, nicht den Akku zu killen. Also ist es möglich.
Ich schätze aber, dass man auf Dauer eine eigene Jabber-Bibliothek dafür schreiben muss.
Es wäre vielleicht auch sehr sinnig, die Diskussion aus dem Lima-Forum in ein eigenes zu schieben (oder in einen Bugtracker, mir egal). -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Für die Entwicklung könnt ihr eine Lima-City Gruppe gründen (https://www.lima-city.de/groups/action%3Acreate) und in dem Unterforum diskutieren. Dafür braucht niemand einen neuen Account anlegen oder so, und ihr kennt einander eher, als dass jemand noch andere Namen wählt.
Jenachdem ob das Projekt öffentlich oder privat entwickelt werden soll bietet sich Github oder Bitbucket an. Da habt ihr auch die Möglichkeit für ein bisschen Verwaltung. Damit entstehen euch während der Entwicklung erstmal an sich keine Kosten.
Übrigens nutzt WhatsApp kein Jabber direkt, sondern eine eigene Weiterentwicklung des XMPP Protokolls, so wie Facebook und Google auch. WhatsApp nutzt letztendlich aber speziell für die Plattform Pushservices. Im Fall von Android übernimmt Google die Übertragung, es wird also von WhatsApp die gleiche Technik wie Hangouts benutzt. Google hat für diese Push Sachen was feines, was den Akku schont.
Warum ich das mit Hangouts in Verbindung bringe ist
Starte die (Google) Hangouts-App, drücke die Menütaste, und wähle Abmelden für alle deine Accounts. Starte Hangouts erneut und melde du dich in deinem/n Account(s) wieder an.
http://www.whatsapp.com/faq/de/android/20887936
Liebe Grüße -
Ist es wirklich schlau auf XMPP zu setzen? Setzt das nicht eine permanente Verbindung voraus, um Nachrichten empfangen zu können? Wenn ja, zerrt das auf jeden Fall gut am Akku... Außerdem ist man in der Regel auf Server von anderen abhängig.
Unabhängig, wie's technisch zu lösen wäre, was haltet ihr von einer (z.B. PHP-Script-)Variante á la Wordpress für den Nachrichtenaustausch? Sprich, ich habe einen Webspace und in der Regel dann auch eine eindeutige Domain, über die dann mein Nachrichtenverkehr läuft. Die Scripte auf den unterschiedlichen Webspaces/-Server können sich über gesicherte/verschlüsselte Verbindungen austauschen. Über eine API ist es dann auch ein leichtes, Clients für unterschiedliche Plattformen bereit zu stellen.
Es handelt sich hier nur um den Ansatz einer Idee, der meines Erachtens gut ausbaufähig ist.
Die Vorteile einer solchen Lösungen sind mannigfaltig. Der Nachteil ist dann der, dass man eben einen Webspace/Webserver und eine Domain haben sollte. Aber das empfinde ich persönlich nicht als großen Stolperstein. Stellt man sich vor, dass z.B. Anbieter eine OneClick-Install-Lösung anbieten könnten...
Beitrag zuletzt geändert: 23.2.2014 7:35:33 von flockhaus -
flockhaus schrieb:
Ist es wirklich schlau auf XMPP zu setzen? Setzt das nicht eine permanente Verbindung voraus, um Nachrichten empfangen zu können? Wenn ja, zerrt das auf jeden Fall gut am Akku... Außerdem ist man in der Regel auf Server von anderen abhängig.
Unabhängig, wie's technisch zu lösen wäre, was haltet ihr von einer PHP-Script-Variante á la Wordpress für den Nachrichtenaustausch? Sprich, ich habe einen Webspace und in der Regel dann auch eine eindeutige Domain, über die dann mein Nachrichtenverkehr läuft. Die Scripte auf den unterschiedlichen Webspaces/-Server können sich über gesicherte/verschlüsselte Verbindungen austauschen. Über eine API ist es dann auch ein leichtes, Clients für unterschiedliche Plattformen bereit zu stellen.
Es handelt sich hier nur um den Ansatz einer Idee, der meines Erachtens gut ausbaufähig ist.
Die Vorteile einer solchen Lösungen sind mannigfaltig. Der Nachteil ist dann der, dass man eben einen Webspace/Webserver und eine Domain haben sollte. Aber das empfinde ich persönlich nicht als großen Stolperstein. Stellt man sich vor, dass z.B. Anbieter eine OneClick-Install-Lösung anbieten könnten...
Deine Idee ist im Kern gut, und ich würde sie völlig unterstützen (bis auf den Part mit PHP, das stinkt nämlich :p), das Problem ist nur, dass man dann dabei ist, ein eigenes Protokol zu schreiben - das braucht Zeit, Zeit und vor allem auch Profils, die sich mit Sicherheit auskennen. Ich denke nicht, dass man das nötige Level an Sicherheit mit ein paar Hobbyentwicklern erreichen kann - leider. Deswegen würde ich gerade auf XMPP setzen.
Eine andere Alternative wäre ein spezieller Email-Client mit Imap-Idle-Unterstützung. -
Denkst du, dass es so schwierig ist? Die benötigten Sicherheitsprotokolle sind ja eigentlich alle vorhanden:
- Möglichkeit PGP o.ä. für direkte Nachrichtenverschlüsselung
- Transport der Nachrichten über SSL oder (weil's für den Anwender sicherlich gut Geld kostet) z.B. über einen SSL-Proxy und ganz "normal" den Port 80 über das http-Protokoll verwenden
Alles Dinge, die bereits vorhanden sind. Es müsste als erstes an der sicheren Kommunikation zwischen zwei Installationen gearbeitet werden. Steht das einmal, sollte der Rest doch auch klappen. Ich finde den Kern dieser Idee auch gut, da man nach belieben einen eigenen Server verwenden kann und sich nicht auf andere verlassen muss. Aber vielleicht ist meine Weitsicht etwas begrenzt...
IMAP-IDLE ist auch eine gute Idee, allerdings wird's dann schwierig, einen Push-Dienst der Nachrichten etablieren zu wollen. Lizenzgebühren, mit denen Apple in der jüngsten Vergangenheit ja auch konfrontiert wurde.
Dass PHP stinkt, ist mir noch nicht aufgefallen, aber vielleicht übertüncht mein Geruch den PHP-Gestank. In diesem Sinne werde ich erstmal duschen
Beitrag zuletzt geändert: 23.2.2014 7:45:07 von flockhaus -
flockhaus schrieb:
Denkst du, dass es so schwierig ist? Die benötigten Sicherheitsprotokolle sind ja eigentlich alle vorhanden:
- Möglichkeit PGP o.ä. für direkte Nachrichtenverschlüsselung
- Transport der Nachrichten über SSL oder (weil's für den Anwender sicherlich gut Geld kostet) z.B. über einen SSL-Proxy und ganz "normal" den Port 80 über das http-Protokoll verwenden
Alles Dinge, die bereits vorhanden sind. Es müsste als erstes an der sicheren Kommunikation zwischen zwei Installationen gearbeitet werden. Steht das einmal, sollte der Rest doch auch klappen. Ich finde den Kern dieser Idee auch gut, da man nach belieben einen eigenen Server verwenden kann und sich nicht auf andere verlassen muss. Aber vielleicht ist meine Weitsicht etwas begrenzt...
IMAP-IDLE ist auch eine gute Idee, allerdings wird's dann schwierig, einen Push-Dienst der Nachrichten etablieren zu wollen. Lizenzgebühren, mit denen Apple in der jüngsten Vergangenheit ja auch konfrontiert wurde.
Dass PHP stinkt, ist mir noch nicht aufgefallen, aber vielleicht übertüncht mein Geruch den PHP-Gestank. In diesem Sinne werde ich erstmal duschen
Nun, wenn man einen eigenen Server betreibt um die Nachrichten zu verwalten, dann kommen noch ganz andere Dinge auf. Aber für die Sicherheit der Nachrichten ist natürlich gesorgt, das stimmt.
Bei dem Problem von Apple ging es nicht um Imap-Idle: http://worldwide.espacenet.com/publicationDetails/biblio?CC=EP&NR=0847654B1&KC=B1&FT=D&ND=4&date=20020220&DB=worldwide.espacenet.com&locale=de_EP
Weder Thunderbird noch K9-Mail (auf Android) hatten je Probleme damit, imap-idle zu nutzen und dementsprechend zu benachrichtigen. ;) Insofern glaube ich nicht, dass wir Imap-Idle ausschließen müssen.
Imap-Idle wäre auch aufgrund der Möglichkeit, Gruppenkonversationen verschlüsselt zu führen schon besser als XMPP. Auch der Akku sollte besser durchhalten. Mediendateien sind kein Problem und für die Tests kann man einfach irgendeine Emailadresse nutzen, dann kann sich ein Teil direkt um die App kümmern während sich ein paar andere um den Server kümmern.
EDIT: Das schöne an imap-idle wäre, dass wir uns nicht um push-Nachrichten kümmern müssten - imap-idle pusht nämlich von alleine und wir könnten bei einer neuen Nachricht einfach vom Gerät aus benachrichtigen.
Beitrag zuletzt geändert: 23.2.2014 9:54:31 von tchab -
Ich habe diesen Thread sehr aufmerksam verfolgt und möchte jetzt auch mal ein paar Anregungen loswerden.
1. Plattformen
Wenn die App mit einem Framework wie z. B. Qt geschrieben wird, ist es relativ leicht möglich diese auch für verschiedene Systeme zu kompillieren. Um bei dem Beispiel Qt zu bleiben: Ich habe hier eine Steuerungs-App die eigentlich für Windows entwickelt wurde. Testweise haben wir einfach mal die App auch für Android und Linux kompilliert. Jetzt nurtzen wir ein Android-Tablet zur Steuerung, was sehr viel schicker aussieht als ein Windows-Rechner.
2. Übertragungen
2.1 XMPP/JABBER & OTR
Vorteil: Nachrichten-Pushs
Nachteil: Auf Grund des Diffie-Hellman-Schlüsselaustauschs von OTR keine Gruppen und Offline-Nachrichten möglich, XMPP-Server erforderlich
2.2 PGP & Webservice
Vorteil: Offline-Nachrichten, Gruppen, Webserver reicht aus
Nachteil: Keine Nachrichten-Pushs
2.3 PGP & IMAP
Vorteil: Offline-Nachrichten, Gruppen, Nachrichten-Pushs
Nachteil: IMAP-Server erforderlich
-
Die Contact Discovery ist ein bisher noch nicht wirklich zufriedenstellend gelöstes Problem:
https://whispersystems.org/blog/contact-discovery/
Bloom Filter könnten aber tatsächlich eine zumindest partiell zufriedenstellende Lösung sein. -
sggesa schrieb:
2. Übertragungen
2.1 XMPP/JABBER & OTR
Vorteil: Nachrichten-Pushs
Nachteil: Auf Grund des Diffie-Hellman-Schlüsselaustauschs von OTR keine Gruppen und Offline-Nachrichten möglich, XMPP-Server erforderlich
Unter Jabber kann man auch PGP verwenden, dadurch wäre dann nur noch der Nachteil vorhanden, dass ein XMPP-Server erforderlich ist.
Einen ähnlich Ansatz verfolgt z.B. die App Threema, welche aber meines Wissens nach kein XMPP verwendet. Deren FAQ sind durchaus interessant und geben einige Anregungen zu diesem Thema:
https://threema.ch/de/faq.html -
Stimmt, der Link ist wirklich interessant. Das Modell mit den farbigen Punkten für die Sicherheitsstufen finde ich gut. Anscheinend setzt Threema auf einen pull-Webservice der durch GCM-pushs angestoßen wird.
-
sggesa schrieb:
Stimmt, der Link ist wirklich interessant. Das Modell mit den farbigen Punkten für die Sicherheitsstufen finde ich gut. Anscheinend setzt Threema auf einen pull-Webservice der durch GCM-pushs angestoßen wird.
Das mit den Punkten ist ja nur eine GUI-Frage. Interessant sind eher die technischen Hintergründe, z.B. warum gerade der Google-Service verwendet wird (Energiesparen) und warum z.B. OTR nicht zum Einsatz kommt. -
Ok... ich hab gerade den ganzen Thread durchgelesen und muss mal einiges dazu loswerden. Ich hoffe mal die Diskussion ist noch aktuelle.
TL;DR: Nutzt euere Euphorie lieber um die Projekte TextSecure oder Surespot zu unterstützen.
Zum einer neuen WhatsApp Alternative sinnlos und eine Verschwendung an Zeit und Ressourcen. Die Fixierung auf XMPP als Protokoll ist da ein sehr guter Ansatz. Es ist ein Standard und auch ziemlich verbreitet. Jabber ist der alte Name für XMPP, nichts mit Weiterentwicklung. XMPP und Jabber werden sozusagen Synonym gebraucht.
XMPP bietet alles, was man von einer modernen Chatplattform erwartet: Benutzerlisten, Gruppenchats, Avatare, Datenübertragung und via Jingle sogar Audio- und Videochats. Durch Transports kann man sogar ICQ, IRC oder andere "legacy" Accounts einbinden. Hinzu kommt da noch die dezentrale Serverlandschaft und die parallele Nutzung von mehreren Geräten aus.
Wenn ihr das Ding verschlüsseln wollt. Weg von OTR, dabei müssen beiden User gleichzeitig Online sein, bei mobilen Endgeräten kann man das nicht erwarten. PGP mit einem Schlüsselpaar bietet sich da schon eher an. Gruppenchats müssten Symmetrisch verschlüsselt werden. Da könnte es sogar schon ein XEP dafür geben.
Die PGP-Keyserver (zb. pgp.mit.edu) kann man dann auch zum "finden" von Kontakten verwenden, weshalb das hochladen des Kontaktbuches wegfallen kann. Ein PGP-Key hat auf einem Keyserver grob gesagt 3 Werte: eMailadresse (bei XMPP halt die JID), ein Kommentar und den Namen des Schlüsselinhabers. Sowohl Name als auch Kommentar könnte die Handynummer des gesuchten Kontaktes sein. Beim finden hat man dann neben dem Öffentlichen Schlüssel auch die JID des Kommunikationspartners. Die JID selbst, sollte man zufällig generieren, da dem 0815-User das nicht interessiert.
Und kommt mir jetzt nicht mit Hashen der Telefonnummer. Alle möglichen Handynummern (12 Zahlen) zu hashen bekommt jeder High-End-Rechner an einem Abend hin. Also kann man sich das sparen.
Bei Jabber selbst müsste man einiges Runterbrechen um es Mobil ordentlich und einfach Bedienen zu können. Die bisherigen XMPP-Clients (zb Xabber oder Beem) sind den Desktopclients ziemlich ähnlich. Bei WA werden Chats nach der letzten Nachricht sortiert und nicht nach Name oder "online/offline"-Status.
WA zeigt auch, dass weniger oft mehr ist. Das KISS-Prinzip sollte bei jeder Chatapp im Vordergrund stehen.
Aber bevor ihr jetzt was eigenes schreibt, unterstützt die momentan schon in den Startlöchern stehenden Projekte mit den gleichen Zielen: TextSecure2.0 oder Surespot.
Um eine ordentliche Alternative zu WhatsApp zu werden müssen für alle Plattformen Clients vorhanden sein.
Schätzungsweise wird Telegram das Rennen machen, leider ist deren Service zentral und nicht vollständig Frei (Freie Software).
just my 2 cents -
@ghlan: Da hast du einige wahre Punkte angesprochen… Ich habe mir schon gedacht, dass es bereits einige solcher Projekte gibt. Trotzdem möchte ich das (eigene) Projekt noch nicht ganz aufgeben.
-
Schade @ghlan, ich kann leider noch nicht bewerten, aber ähnliche Gedanken hatte ich auch. Kleine Brötchen backen und vielleicht die Energie in ein vorhandenes, viel versprechendes, offenes Projekt legen, als noch ein unbedeutendes in den Teich zu schmeißen. Eine Ausnahme wäre ein interessanter neuer Ansatz oder Idee. Die ist aber hier nicht gegeben, denn alle Vorstellungen und Wünsche sind nicht's neues.
Falls es jemand interessiert - zum Stichwort Messenger und Kryptografie habe ich gerade auf Golem einen, wie ich finde, interessanten Kommentar gelesen, der vielleicht den einen oder anderen hier auch interessiert..
Beitrag zuletzt geändert: 28.2.2014 22:52:33 von flockhaus -
@funnyweb: Ich kenn' jetzt deine Fähigkeiten der Programmierung betreffend nicht, aber einen eigenen Messenger anzufangen ist Sinnlos.
- Man braucht viele User, welchen den Service auch nutzen. Andernfalls hat ein Messenger wenig Sinn.
- Viele User bekommt man nur, wenn man von vielen (am Besten alle) Plattformen Zugriff darauf an.
- Du kennst dich in der Materie der Messenger kein bisschen aus. Den Schluss ziehe ich durch deine Unkenntnis über schon vorhandene Projekte, deren Ziele zu deinem kongruent sind.
Mein Tipp an dich: Versuch nicht das Rad neu zu erfinden. Die Probleme auf denen du dabei stößt, sind von anderen schon längst beseitigt worden. Bring deine Energie lieber bei einem der Projekte ein, welche deine Ziele schon umgesetzt haben (ChatSecure, Surespot, TextSecure). Da gibt es jeweils noch einiges an Bugs und Features die herausgearbeitet werden müssen. "Lurke" dazu am besten eine Weile in deren Mailinglisten, Chats oder Foren rum.
Falls du allerdings von Anfang an was selbst programmieren willst, dann versuche doch ein Programm für ein noch nicht unterstütztes mobiles Betriebssystem für eines dieser Systeme anzufangen. Da hättest du auf jedenfall schonmal eine potentielle Userbasis, welche du mit einem eigenen System wahrscheinlich niemals erreichen würdest.
Versteh mich bitte nicht falsch. Ich will dir hier nicht den Wind aus deinen Segeln nehmen, eher versuche ich Synergien zu fördern.
Oder mit flockhaus' Worten:
"Kleine Brötchen backen und vielleicht die Energie in ein vorhandenes, viel versprechendes, offenes Projekt legen, als noch ein unbedeutendes in den Teich zu schmeißen."
@flockhaus: Dem Golem Kommentar kann ich nur Zustimmen. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
