Dezentrales Soziales Netzwerk

[Kr0e]

Hallo!!

Ein Buzzword Titel und eigentlich auch im falschen Forum.

ABER!

Ich würde gerne eine Diskussion starten um Meinungen, Ansichten, Tipps und Ideen auszutauschen.

Vorwort:

Ich weiß, dass es bereits Ideen wie diese gibt (Diaspora, etc)
(musste ich heute feststellen, wie immer ist man nie der erste)


1. Was haltet ihr von der Grundidee, ein System wie Facebook (konzeptionell) dezentral zu gestalten ?
2. Welche technischen Hürden gäbe es, eurer Meinung nach ?
3. Hätte jemand Lust ggf. das ganze in Form eines Github/OpenSource Projekts zu versuchen ?


Nun zu meinen ersten Ansätzen, die ich mir heute auf dem Weg mal gemacht habe:

Grundidee: Jeder User hostet sein eigenes Profil. (Diaspora und Konsorten gehen ja hier den Umweg auch wenn natürlich nicht ausgeschlossen wird, dass jeder hostet)

1. Also praktisch hat jeder User nen Http Server am Laufen. (Klar, hier wäre NAT ein erstes Hindernis).

2. Jeder User kommuniziert nicht direkt mit seinen Freunden, sondern über ein Webinterface mit dem lokal laufenden Server. Anfragen an Freunde werden von diesem Server gemanaged. Also möchte man die Seite von FReunde xy sehen, so fungiert der lokale Server als Proxy.

Warum ? Ich dachte daran, weil User ja offline sein können. Ergo, auch kein Webserver läuft. Mit der PRoxy Idee, könnte man einer Art Cache einbauen (In Form einer lokalen kleinen Datenbank (SQLite)).

Hier ist noch viel Spielraum für Ideen und Erweiterungen.

-------------
Hürden aus meiner Sicht:

1. Holepunching & Dynamische Addressen der Clienten (Vermittlungsserver ??)
2. Suchen von Leuten (Hängt zur Hälfte mit Punkt 1 zusammen)
3. Welche Technologie/Sprache/Framework ??

-------------


Unerlässlich:

Einfache Installation (Diaspora verlangt Ruby on Rails + MongoDB - Nunja...)
Sicher (Verschlüsselt und nur Freunde sollen etwas sehen können, wenn man es will)
Ggf. hinterher Lastverteilung im Fall, dass es öffentliche Profile gibt, die oft gesehen werden und einen einzelnen Server überlasten.


Bitte zerfetzt, die Idee nicht nach dem Motto "Das schaffst du eh nie". Es geht hier in erster Linie um ein Open Source Projekt und 2tens dürfte die größte bzw. allergrößte Hürde vermutlich das Bekanntmachen werden.

Würde mich über Ideen, Anregungen und konstruktive Diskussionen freuen =)

Gruß,

Chris

 

[Robokopp]

Also die Idee klingt schon mal gut, dass aber mir sind ein paar Dinge unklar:
-was passiert, wenn ein User offline ist? Existiert er dann quasi nicht für die anderen oder wird sein Profil gecached. Falls ja, wäre das ja am Sinn der dezentralität vorbei.
-Was passiert wenn ein User den PC wechselt/der alte kaputt geht? Dann müssten seine Daten ja weg sein.
-wenn viele Leute gleichzeitig auf einen Nutzer zugreifen, der dann vlt auch noch eine lahme internetanbindung hat dann wäre es eher suboptimal. Da müsste man dann die Zugriffe beschränken oder ähnliches

Ich glaub das ist nicht wirklich massentauglich.

 

[tuxedo]

Gibt's das nicht schon? MIr war so als hätte ich dazu schonmal was gelesen... *suchen geh*

[EDIT]
Okay, wer lesen kann ist kla rim Vorteil. Im ersten Post wurde ja schon Diaspora genannt. Und genau das meinte ich. Was grenzt denn deine Idee von der Diaspora-Idee ab? Außer dass es "einfacher" sein soll? Wenn's da nicht ein wichtiges Feature in deiner Idee gibt, würde ich fast sagen: Besser mithelfen Diaspora einfacher zu machen ...[/EDIT]

 

[Landei]

Gibt's das nicht schon? MIr war so als hätte ich dazu schonmal was gelesen... *suchen geh*

"Diaspora", wie der TO schon geschrieben hat.

 

[Kr0e]

Diaspora geht davon aus, dass die Hubs online ständig. Daher wird auch geraten, dass sich die User Hosts mieten sollen, was meiner Ansicht nach absolut benutzerunfreundlich ist. Allein schon die Tatsache dass das ganze in Ruby geschrieben ist und MongoDB zwingend erfordert.... Das ist unter Windows (Und 99% aller Facebook User benutzen bestimmt Windows) gar nicht mal so einfach.


@Robokopp

Danke für deine Anregungen.

Punkt 1:
Warum genau wäre Caching am Ziel vorbei ? Ich dachte halt an folgendes: Wenn ein User offline is, kann er ja sowieso nicht sein Profil ändern, insofern wäre Caching hier sehr sinnvoll.
- Hier kam mir die Nacht noch ein anderes Problem in den Sinn: Updates eines Freundes werden nur gesehen, wenn beide gleichzeitig online sind. Das wäre vermutlich das größte Problem und bislang weiß ich darauf keine Antwort...

Punkt 2:
Das mit dem Neuinstallieren kam mir auch schon in den Sinn. Man müsste ggf. Export/Import Funktionen einbauen, damit jeder User seine Identität portieren kann.


Punkt 3:
Das Probleme dass viele Leute auf einen zugreifen könnte in der Tat kritisch werden. Vor Allem was Ressourcen wie Fotos und Movies angeht. Ich würde behaupten dass die reinen Textinfos würden DSL heutzutage nicht mehr auslasten... Klar bei VIP Profilen wirds hart... Die müssen über richtige Server angebunden werden.

Zu Punkt 3: Profilfotos könnte man ggf. über Gravater regeln, auch wenn das nicht grad benutzerfreundlich ist. Aber was allgemeine fotos und videos angeht wäre es in der Tat nicht mehr so easy.

 

[musiKk]

tuxedos edit sollte nicht viel hinzuzufügen sein. Besser beim aktuell vielversprechendsten Kandidaten Diaspora mithelfen, als einen weiteren "Konkurrenten" zu erstellen, der Diaspora evtl. nur schwächt (erinnert mich auch ein wenig an die Situation bei Standards).

Natürlich ist Wettbewerb generell etwas gutes, aber in einem Markt, der komplett von einem Player abgedeckt wird, sollten imho zunächst die Kräfte vereint werden.

Ich halte generell nicht so viel davon, dass jeder Nutzer seinen eigenen Server laufen lassen muss. Das sollte technisch versierten vorbehalten bleiben, ansonsten ist die Hürde zur Beteiligung einfach zu hoch. Warum sollte sich ein Nutzer erst mit Port Forwarding auseinandersetzen müssen? In Zeiten von Raspberry Pis wird das aber immerhin einfacher (oder zumindest kostengünstiger). Das Problem bei zentralen Architekturen jeglicher Art (das betrifft daneben vor allem auch die Vergabe von SSL Zertifikaten durch CAs) ist, dass man sich nicht aussuchen kann, wem man vertraut. Ein dezentrales Netzwerk sollte Hubs anbieten, die durch genannte technisch versierte Nutzer betrieben werden (z. B. einer im Freundeskreis oder durch eine vertrauenswürdige Organisation wie den CCC oder die EFF). Jeder Nutzer kann für sich entscheiden, welchem Hub er vertraut.

Um dieses eigentlich schon zu komplizierte Verfahren etwas zu vereinfachen, bräuchte man auf jeden Fall einen zentralen Index. Und damit gehts mit Problemen wie Zensur los (hey, dieser Hub wird ja von Kinderschändern/Raubkopierern/Staatsfeinden betrieben). Ok, also brauchen wir 3rd Party Indexdienste (wie bei den Android Apps mit Google Play und "Rest").

Im Ende läuft es meines Erachtens nicht auf eine spezielle Platform hinaus, sondern auf ein Protokoll (oder eine Sammlung derer), mit dem die verschiedenen Platformen miteinander kommunizieren können; wie bei XMPP. Gut, das widerspricht meiner Prämisse am Anfang wieder...

Der langen Rede kurzer Sinn: Ich denke, ein solches Projekt ist von riesiger Komplexität gekennzeichnet. Zu Beginn dürfte das erstmal auf ein Dokumentations-/Brainstorming-Projekt hinauslaufen, in dem die Architektur aufgestellt wird mit allenfalls prototypischer Entwicklung nebenher. Und da das ein Hobby-Projekt ist und kein Vollzeitjob (?) würde ich dafür auch ein paar Jahre veranschlagen. Sprachen und Frameworks sind in der Zeit noch völlig außen vor.

So. Ich hoffe, das kommt nicht als Dein gefürchtetes "Zerfetzen" rüber. Ich denke eben, dass es bei dieser Thematik nur zwei Möglichkeiten gibt: Entweder man schafft in relativ kurzer Zeit eine halbgare Lösung oder in extrem langer eine gute. Das soll natürlich niemanden davon abhalten, loszulegen. Im schlimmsten Fall lernt man dazu, im besten kommt etwas brauchbares heraus.

 

[Kr0e]

Das mit den Hürden war auch das erste was mich an Diaspora gestört hat. Hatte auch nen Fork und mal geschaut wie das ganze aufgebaut ist. Generell (aus technischer Sicht) ist das Projekt sogar gar nicht mal schlecht aber ich befürchte die haben von Anfang an aufs falsche Pferd gesetzt. Ich hatte mit einem Core-Dev geschrieben und er sagte, dass die gewählten Technologien schlicht und einfach falsch sind (wenn man die Voraussetzung hat: Einfache/Idiotensichere Installation - Oder wie es ein anderer formuliert hat: Ich glaube erst an den Erfolg von Diaspora wenn mir meine Schwiegermutter auf die Pinnwand schreibt)


Fazit: Ein dezentrales Modell bringt haufenweise Hürden mit sich. Obwohl mich die Idee an sich doch äußerst reizt. Vlt. ist die Zeit noch nicht reif, die Leute noch nicht 100% online und noch nicht alle haben 50.000 DSL. ICh könnte mir aber vorstellen, dass in Zukunft die Web-affinen Menschen mehr werden, die Technik besser wird, die Netzabdeckung sich vervollständigt und auf lange Sicht solche Ideen vermutlich Facebook überholen. Die Menschen müssen sich einfach oft genug ärgern um Alternativen in Betracht zu ziehen.

Was mich fasziniert hat, ist dass diese Idee extremen Anklang gefunden hat. Die haben wohl ne Menge durch Projekte wie KickStarter bzw. Spenden bekommen, auch wenn die zur Zeit erstaunlich wenig vorzuweisen haben.

Ich werde einfach mal weiter lesen/überlegen und planen. Falls sich daraus ein handfestes Ziel ergibt, werde ich hier auf jeden Fall nochmal schreiben.
ABER: das soll euch nicht abhalten , weiterhin Ideen zu äußern

 

[c_sidi90]

Was siehst du als den größten Vorteil, alles auf einzelnen hosts laufen zu lassen?

 

[Kr0e]

Die 100%ge Kontrolle über seine Daten. Das wäre für mich das Topargument. Und die Verteilung der Last aus Netzwerksicht.

 

[c_sidi90]

Klingt aufjedenfall interessant, habe von einer solchen Lösung im Bezug of social networkds noch nie gehört. Denke aber, dass geübte Personen ziemlich schnell die Schwachstellen einer solchen Architektur aufdecken werden und das ausnutzen könnten.

 

[SlaterB]

@Kr0e
> Die 100%ge Kontrolle über seine Daten.

wenn du sie einmal an gewisse andere Server == Freunde verteilst, ist es mit den 100% strenggenommen ziemlich aus,
aber schon einige höhere Kontrolllevel reichen natürlich

@c_sidi90
> Denke aber, dass geübte Personen ziemlich schnell die Schwachstellen einer solchen Architektur aufdecken werden und das ausnutzen könnten.

das ist ja kein kompletter Beinbruch,
sowas fällt auf und kann korrigiert werden,
sowas wird kaum an große Firmen legal verkauft und zu Werbezwecken eingesetzt usw.

mit einem zentralen System sind alle Probleme dagegen permanent da und offiziell, je nachdem was man dem Anbieter zutraut

 

[darekkay]

Die 100%ge Kontrolle über seine Daten..

.. hast du nur, wenn du sie gar nicht erst online stellst. (und selbst da sind es nicht ganz 100%)

"Höherer Kontrolle" könnte man eher zustimmen

 

[Robokopp]

Caching wäre am Ziel vorbei, weil du Profile der User die offline sind über einen zentralen Server bereitstellen musst. Du kannst ja mal schauen wie viele User beispielsweise bei Facebook online/offline sind. Ich denke es sind mehr gleichzeitig offline als online. Das würde heißen, dass du einen Großteil über deinen Server verwalten musst. Und bei profiländerung muss das auf dem Server gespeicherte Profil aktualisiert werden.

Die Idee ist zwar cool, wenn vorallem da man ja theoretisch die volle Netzwerk last auf seine User verteilen könnte, aber in der Regel wird das nicht klappen

 

[SlaterB]

> Das würde heißen, dass du einen Großteil über deinen Server verwalten musst.

ein Email-Postfach enthält auch ne Menge Altkram, paar Freunde lokal zu speichern ist wohl annehmbare Aufgabe,
interessant wird die erste Kontaktaufnahme, wie findet man überhaupt jemanden, darf man Daten von Dritten kopieren wenn direkt gerade offline?

vergleichbar mit echten Leben, bevor man eine Person X selber kennenlernt hört man vielleicht erst, was andere schon Bekannte sagen,
an persönlicher Meinung und (richtigen oder falschen) allgemeinen Informationen

---

edit:
die ständige Aktualisierung könnte sich auch gut durch den Netzwerkgraphen fortpflanzen,
Server A kennt Profil B zum Zeitpunkt k2,
Server C kennt Profil B zum Zeitpunkt k1 (oder behauptet es zumindest), und hat Berechtigung (da wirds gegebenenfalls wichtig)?
dann kann im Hintergrund A an C den neuen Stand senden usw.

wer welches Profil kennt ist freilich auch schon ne Info, die nicht unbedingt ausgetauscht werden will/ soll,
aber wenn sich A und C kennen und diesen Austausch vereinbart haben..

B muss schon darauf vertrauen, dass alle anderen mitspielen, wenn A erstmal die Daten hat, kann A sie auch an die ganze Welt liefern

 

[tuxedo]

Ich denke das ganze wird erst richtig praktikabel wenn man folgende 3 Dinge berücksichtigt:

1) Flächendeckendes IPv6 .. Kein Stress mehr mit NAT und Portforwarding. Wobei dann wohl Firewalls ein Thema werden. Aber vielleicht gibt es dann auch DSL-Router mit "DMZ-Buchse"?? Wieso DMZ-Buchse? Siehe 3 ...
2) Ein gesteigertes Datenschutz-Bewusstsein: Wenn die Leute mal verinnerlicht haben, dass sie Ihre Daten herschenken, und sie nichtmal selbst darüber entscheiden können wann deren Quelle versiegt (Stichwort: Daten löschen bei Facebook.. werden aber doch nicht wirklich gelöscht.).. Erst wenn dieses Bewusstsein Eintritt, sind die Leute u.U. bereit für Punkt 3:
3) Eine kleines "Social Network"-Hardware-Kistchen... Da liegen alle persönlichen Daten drauf. Daten löschen? Kein Thema. Einfach von der Kiste löschen. Fertig. Okay, andere Bilder könnten kopiert und weitergereicht worden sein. Aber immerhin ist die Ursprüngliche Quelle versiegt. Damit's fast nix kostet: Sowas wie RaspberryPi reinstecken und das ganze für, sagen wir mal 50-75EUR anbieten. Okay, das ist teurer und aufwendiger als das bisherige Facebook und Co. Aber wenn Pnkt 2 erfüllt ist, dann sollte das machbar sein. Und damit die Einrichtung nicht zur Hölle wird: DMZ-Buchse am Router verwenden.

Alles in allem halte ich persönlich eh wenig von sozialen Netzen in diesem Ausmaß. Früher haben sich gleichgesinnte noch in Foren getroffen, und Kontakte, die man persönlich kannte hat man tatsächlich persönlich getroffen. Und da wo die Entfernung zu weit zwischen beiden zu weit ist: Da gabs meines erachtens Genug möglichkeiten das zu überbrücken (Skype, ICQ, Email und zur Not auch mal einen dedizierten Cloud-Dienst wie Flickr (um die neusten Urlaubsfotos zu kommunizieren)). Aber gut, das ist eher Offtopic ...

- Alex

 

[Kr0e]

@Robokopp:

Mit Caching meine ich, dass die User selbst die Daten von anderen cachen! Kein Server! Also nach dem Motto:

Ich richte meine Anfrage an meinen lokalen Server, dass ich User xy sehen will. Mein lokaler Server prüft, ob der User erreichbar ist, wenn nicht, gibts die Seite aus dem Cache, wenn kein Cache vorhanden ist.. nun gut. Das wäre das gleiche Problem wie: Updates sieht User A von User B nur, wenn beide online sind.

 

[Lumaraf]

Ohne Server die sich um eine schnelle Weitergabe der Daten an die Freunde kümmert wird man häufig das Problem haben das Daten erst sehr spät oder garnicht bei den Freunden ankommen. Solange die Server nicht den Inhalt der Nachricht kennen sehe ich aber kein Problem darin. Mein Vorschlag dazu wäre das ganze mittels asymetrischer Verschlüsselung zu kontrollieren. Der Benutzer signiert den öffentlichen Schlüssel des Servers und berechtigt ihn dadurch die Nachrichten zwischenzuspeichern. Wenn man die Daten dann noch mit dem öffentlichen Schlüssel des Users verschlüsselt kann nur der User an den die Nachricht geht diese auch lesen.

 

[Guest2]

Moin,

die technischen Hindernisse einen lokalen Server zu betreiben sind imho nicht so groß. Das P2P Filesharing zeigt doch, das jedes Kind dazu in der lange ist! Es muss lediglich so ausgelegt sein, das die Software einfach auszuführen ist. Im Allgemeinen gibt es aus der P2P und Darknet Ecke viele Ideen und Ansätze, die man bei einem dezentralen sozialen Netzwerk als Ideengrundlage nutzen könnte.

Auch die Sicherheit des eigenen Profils ließe sich verbessern, wenn die Profile nur als verschlüsselte und signierte Datensätze im Netz verteilt werden. Erst wenn einer "Freundschaftsanfrage" zugestimmt wird, werden die notwendigen Schlüssel ausgetauscht. Damit sind die Profile hoch verfügbar, können aber trotzdem nur von berechtigten gelesen werden. Das geht solange gut, wie keiner der "Freunde" den notwendigen Schlüssel extrahiert und weitergibt, was aber bedeutet, dass die Sicherheit des eigenen Profils von der Qualität der eigenen Freunde abhängt, was imho in Ordnung wäre.

Das größte Problem ist imho eine kritische Nutzermenge zu überschreiten. Zum Beispiel Diaspora oder auch G+ wurden gehypt, trotzdem gibt es nur so wenige Nutzer dort, das es sich praktisch nicht lohnt dort Zeit zu verbringen. Und wenn das Netz trotzdem bekannt werden sollte, wird es erst richtig unangenehm. Viele verstehen leider nicht, das ein zensurresistentes und datensparsames Netz natürlich für alle zensurresistent und datensparsam ist. Also auch für Pädophile, Terroristen, Rechte und soziale Löcher im Allgemeinen. Wenn Tante Frieda erfährt, dass die Enkelin Chantal im vermeidlichen Pädohilnetz unterwegs ist, könnten die Entwickler auch schnell mit der brennenden Mistgabel durchs Dorf getrieben werden.

Aber spannend fände ich das schon.

Viele Grüße,
Fancy

 

[Kr0e]

@Lumaraf & Guest2:

Danke für eure Ansätze! Das mit der Verschlüsselung klingt auf jeden Fall notwendig und somit könnte man tatsächlich auch zentrale Server nutzen. Im Prinzip also PGP/GPG mäßig.

Das Privatsphäre auch missbraucht werden könnte, vor allem eine derartig gute, stimmt schon. Wenn man drüber nachdenkt, fallen einem viele Beispiele ein, dass Privatsphäre auch seinen Preis hat, das ist wahr.

Aber andererseits sollte Privatsphäre und Sicherheit niemals zusammen betrachtet werden. Wo zieht man da die Grenze ? Telefonüberwachung/Emailkontrolle, ja sogar Paketkontrolle. Wo führt das hin... Ich denke man kann nicht beides gewährleisten. Entweder ,- Oder !

 

[Guest2]

Zentrale Server würde ich persönlich weitgehend vermeiden. Zum einem werden dadurch kritische Systeme geschaffen deren Ausfall das Netz destabilisieren können und zum anderen werden laufende Kosten erzeugt. Ein reines P2P- oder Hybrides P2P-Netz hat solche Nachteile nicht.

JXTA bzw. die passende Java Implementierung JXSE könnten z.B. einen Blick wert sein. Dort gibt es die P2P Grundstruktur, in der einige der üblichen P2P Probleme bereits gelöst sind. Allerdings stammt das Projekt ursprünglich von SUN und Oracle zickt nun rum. chaupal könnte der Community Nachfolger sein / werden, aber da ist der letzte Commit auch schon wieder über ein Jahr alt. Nichtsdestotrotz, Ideen für die technischen Probleme gibt es viele.

Bei der Sache mit Freiheit vs. vermeintlicher Sicherheit entscheiden sich leider viele für die vermeintliche Sicherheit. Mach doch mal eine Umfrage, in welchem Netz sich die Leute lieber anmelden, Facebook oder in dem Netz, in dem auch die Pädophilen sind? Das Schlagwort reicht doch schon, kaum einer denkt dann weiter.

"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen, wird am Ende beides verlieren" (Benjamin Franklin).

Viele Grüße,
Fancy

 

[tuxedo]

die technischen Hindernisse einen lokalen Server zu betreiben sind imho nicht so groß. Das P2P Filesharing zeigt doch, das jedes Kind dazu in der lange ist!

Diese Aussage ist leider schlicht falsch. Um einen Browser zu bedienen braucht's nicht viel wissen:

* PC einschalten
* Browser-Symbol anklicken
* Adresse eingeben
* Maus benutzen

Jeder der es sich zutraut einen Rechner einzuschalten beherrscht das mittlerweile.

Der Benutzerkreis der P2P Programme bedienen und einrichten kann, unterscheidet sich jedoch Grundlegend von dem, der ledichlich weiß wie man einen Brief druckt oder Emails schreibt und im Web surft, und letztendlch soziale Netze benutzt. Hinzu kommt, dass sich die beiden Kreise nicht nur vom Anwendungsgebiet und Wissen unterscheiden, sondern auch noch in der Größe.

Alles was also über die Bedienung des Browsers hinaus geht, braucht eine überwindung einer Hemmschwelle. Und der Antrieb dazu, nämlich der Grund für ein dezentrales Soziales Netz - der Datenschutz und die Sicherheit, fehlt hier noch komplett. Was glaubst du warum so viele WhatsApp benutzen, statt einer der sicheren Alternativen:

1) Weil's einfach ist
2) Weil's die anderen genauso machen

Und dieses Verhalten in Bezug auf soziale Netze zu kippen.. Puuh. Das ist, wenn Facebook sich's nicht granatenmäßig weltweit mit den Usern verscherzt, derzeit eine Lebensaufgabe.

- Alex

 

[tuxedo]

Was ich mir aber vorstellen könnte:

Es nutzen ja immer mehr die sozialen Netze auf dem Handy oder Tablet unterwegs, statt daheim am großen, klobigen Rechner oder Laptop:

Warum also das ganze nicht komplett mobil auslegen? Gibt's hier NAT-Probleme? Weiß das einer? Wenn man also mobil online keine NAT-Probleme hat, dann bräuchte man nur eins: Einen Index-Server (bzw. mehrere) wo man "bekannt" geben kann dass man nun online und "da" ist. Dort könnte man dann die aktuelle IP der Freunde erfragen (lokal hat man vielleicht nur eine ID die den Freund identifiziert, so dass der Server nur ID<->IP Paare vorhält) und sich direkt P2P mit denen verbinden. In Zeiten von "PushMail" und Co. sollte das doch kein großes Thema sein. Die mobilen Geräte haben meist auch ausreichend Platz für Bilder und sonstigen Krempel, und haben zudem immer den aktuellsten Stand (bezogen auf Status, Bilder, ...).

Klar, der Traffik könnte nach oben gehen. Aber auf dem Handy muss es ja auch nicht das 16Megapixel Bild sein das zu den Freunden übertragen wird. Dazu noch Caching und gut ist. Die meisten die ich kenne haben sich eh überteuerte Tarife mit viel zu viel Datenvolumen andrehen lassen. VOn daher hätten die dann endlich mal Verwendung für das Volumen

- Alex

 

[D4rkscr43m]

Mach doch mal eine Umfrage, in welchem Netz sich die Leute lieber anmelden, Facebook oder in dem Netz, in dem auch die Pädophilen sind? Das Schlagwort reicht doch schon, kaum einer denkt dann weiter.

Manchen Leuten muss man eben die Augen öffnen, dass bei Facebook viel, viel mehr Pädophile sind, als sich jemals in so einem privaten Netz anmelden würden.

Ich finde die Idee jedenfalls sehr gut!
Eventuell kann man sich dafür auch etwas von RetroShare angucken, dort gibt es ja auch keine zentralen Server, wobei es da deutlich einfacher ist mit Usern umzugehen, die nicht online sind. Die sind einfach nicht erreichbar = Offline ... es gibt dort ja quasi keine "Seiten" wie in sozialen Netzwerken.

Allerdings muss ich auch tuxedo zustimmen, dass die Zielgruppe für soetwas etwas "klein" ist.
Aber diejenigen die an so einem Netzwerk interessiert wären, sind meist die, die es auch problemlos einrichten können.

 

[TheDarkRose]

Auf Mobilgeräten ist das NAT Problem noch präsenter, da hier oft ein Carrier-Grade NAT eingesetzt wird. Also ein NAT beim Provider selbst, wo sich dann nichts mehr mit Portforwarding und Co spielt.

 

[tuxedo]

@TheDarkRose

Hmm, okay. Mist. Doofe Sache. Dann würde man für dieses Szenario nicht um Relay-Server herumkommen: Alle Mobilen Geräte bauen eine Verbindung zu einem oder mehreren Relay-Server auf, über welche die Daten von Smartphone A zu Smartphone B transportiert werden. Das noch mit SSL gepaart und gut ist. Ist nur die Frage: Wer zahlt die Server und den anfallenden Traffik? Und: Wie bekommt man das hin so dass es gut mitskaliert?
Einen Vorteil hätte das dann wieder: Der Heimische PC würde prinzipiell auch gehen. Nur hat der vielleicht nicht den gleichen Content zu bieten wie das Smartphone...

- Alex

 

[Kr0e]

Hi!

Grad mal wieder bissel gegooglet. Apropro Google... WebRTC.

Die Technik steckt noch in den Kinderschuhen aber ums zusammenzufassen:

Browser p2p mit Video/Audio Streaming inklusive. Das beste: NAT Punchthrough etc wird von Chrome, etc übernommen. Sogar mobile Geräte werden bald unterstützt.

Ja, man braucht allerdings wie immer einen Verbindungserver, aber ansich klingt die TEchnik/Idee dahinter genial.

Damit wäre die Hürde genommen!

 

[Guest2]

Grundsätzlich sehe ich in Mobilgeräten auch keine so große Hürde. Die meisten nutzen dort eh Apps, um auf soziale Netzwerke zugreifen zu können. Sofern es aus den Apps heraus möglich ist, ausgehende Verbindungen aufzubauen, sollte es auch problemlos möglich sein, auf das P2P Netz zuzugreifen. Natürlich ist die Connectivität aufgrund des Carrier NAT und der Bandbreite geringer, sodass die Mobilgeräte nicht sonderlich zur Infrastruktur beitragen können, aber solange es auch noch DSL Nutzer gibt, sollte das kein großes Problem darstellen.

Viele Grüße,
Fancy

 

[trääät]

ich find das thema durch aus interessant ... habs aber bis jetzt nur so nebenbei mitverfolgt ...

grundsätzlich muss man zwischen verschiedenen "de-zentralen" strukturen unterscheiden ... denn die meisten "de-zentralen" netze haben irgendwo immer mindestens einen zentral bekannten knoten auf den es dann doch irgendwie ankommt ...
natürlich kann man auch diesen einen knoten "de-zentralisieren" in dem man ihn selbst auf mehrere knoten aufteilt ... aber das grundproblem bleibt : es gibt in fast allen "de-zentralen" netzen immer mindestens einen fix-punkt ... und sei es auch nur die website von der man sich eine knoten-liste für einen bootstap runterläd ...

ein wirklich 100% de-zentrales netz würde es in dem sinne nur geben wenn jede verbindung manuell hergestellt wird ... was wiederum andere kommunikations-kanäle erfordert um die dafür nötigen informationen auszutauschen ...


aber mal davon abgesehen ...

netzwerke ... und halt auch gerade social networks wie man sie gerne nennt leben doch im endeffekt davon das man daten mit seinen mitmenschen teilt ...
also gibt es alleine hier mehrere "gründe" die im gegensatz zur eigentlich grund-idee stehen
1) irgendwie müssen die daten online bleiben obwohl der user offline ist ... > caching im netzwerk / auf zentralem server > keine kontrolle mehr über die daten
2) kommunikation zwischen zwei oder mehr personen nur direkt möglich ... also wenn beide online sind ... womit zeitversetzte kommunikation wie eben "pinnwände" unmöglich werden wenn diese nicht auch wieder im netzwerk oder auf nem zentralen system gespeichert werden
3) wiedereingliederung ins netzwerk : da heutzutage die technik des "dail-up" weit verbreitet ist (und JA : dsl ist in dem sinne auch nur dail-up) hat jeder knoten nach trennen des netzes eine neue IP ... (user von echten standleitungen bei denen sich die IP nicht ändert sind davon natürlich nicht betroffen)
nun können mehrere fälle eintreten :
a: man bekommt die IP eines anderen knoten und wird erstmal als dieser behandelt bis man im netzwerk bekannt gemacht hat das unter dieser ip nun nicht mehr alte knoten sondern man selbst erreichbar ist
b: man bekommt eine dem netz unbekannte ip ... braucht also bootstraping um sich wieder verbinden zu können ... auch wenn die eigene temp-liste mit verfügbaren knoten noch recht in ordnung ist und man über diese bootstrapen könnte so kennen diese knoten ja die neue ip nicht
c: die eigene cache-liste mit verfügbaren knoten ist zu alt und alle dort vermerkten knoten sind nicht mehr erreichbar > zentraler index ...


da es also mehr als nur einen grund gibt das man irgendwo immer einen zentralen punkt braucht ... und dabei beziehe ich mich auch auf große P2P netze ... denn man muss ja auch irgendwo her die knoten-liste bekommen ... stellt sich eigentlich die frage : warum dann versuchen das ganze überhaupt de-zentral zu gestalten ?
sicher könnte man gewisse dinge wie echtzeit-kommunikation direkt als P2P implementieren und somit last vom zentral-system aufs netzwerk selbst umlagern ... aber wirklich viel mehr einsatzgebiete bleiben dann nicht mehr ...
und ob jetzt irgendwelche daten von mir im netzwerk verteilt gespeichert bleiben oder auf nem zentralen server widerspricht dem ziel der "möglichst großen eigenkontrolle der persönlichen daten" ...

als theoretisches system für z.b. ne doktor-arbeit mag das thema ja wirklich interessant sein ... aber wenn man die ganzen negativen seiten betrachtet ist eine praktische umsetzung in meinen augen nur mit leuten möglich die sich mit dem thema so halbwegs befasst haben und wissen was auf sie zu kommt ... für die 0-8-15 facebook-generation und einen großteil der nicht-informatiker wird so ein netzwerk ein buch mit sieben siegeln bleiben ...

 

[Kr0e]

Würde mich ja bedanken, wenn du registriert wärst Also.. danke!

Ein aufschlussreicher Beitrag mit vielen genannten Hürden. Bis auf Punkt 1, kann ich dir leider nicht wiedersprechen =( (Gecachte Pakete sind verschlüsselt und können nur von Freunden entschlüsselt werden (Mit GPG z.b.))

Aber die restlichen Probleme .. tja, leider sehe ich das inzwischen auch so. Ich dachte schon an ein "Kademlia"-ähnliches System. Also jeder User ist eine eindeutige Nummer, alle sind durch ein Kademlia Netzwerk mit einander verbunden. Damit könnte man zumindest das Problem der Konnektivität halbwegs lösen. So machen das ja auch Torrentprogramme die Tracker-Free arbeiten. Nat wäre dann natürlich noch imemr ein Problem , aber das lass ich jetzt mal außen vor.


Alles in allem... : Die meisten Facebook User sind IE 6 Benutzer (im übertragenden Sinn) und kümmern sich weder um ihre Daten noch haben sie ahnung wenn es um schwierigere Dinge geht , als ein Konto bei Facebook erstellen.

 

[tuxedo]

Das Netz an sich muss ja nicht dezentral sein. Das kann ja durchaus, wie bei Facebook auch, zentral sein. Was wichtig wäre (also für mich, wenn ich an einem solzialen Netz teilnehmen wollte): Private Daten wie Bilder, ein Teil der Texte/Schriften/Posts, die Info "mit wem bin ich befreundet",.... dürften nicht auf den Server liegen. Nur so hätte man selbst die Hoheit über seine Daten.

Mit dem Ansatz "Daten liegen auf dem Smartphone statt auf dem Server" ließe sich das machen. Vorrausgesetzt man findet einen praktikablen weg (einer der nicht komplexer ist als das Installieren der App) wie Freunde in meiner Freundes-Liste an meine freigegebenen Bilder, Daten, ... kommen, ohne dass die auf dem Server gespeichert werden müssen. Und dann sollte das ganze im Ganzen auch noch irgendwie skalieren können.

DAS wäre dann schon mal ein Fortschritt gegenüber den traditionellen Social Networks. Zentrale Infrastruktur, aber dezentrasle persönliche Daten (jeder ist Herr SEINER Daten).
Den Umstand dass man dann noch abhängig von der Infrastruktur des Netzwerks ist, werden wohl viele in kauf nehmen können (machen sie ja eh schon).

- Alex

 

[Guest2]

Zentrale Infrastruktur bedeutet im Umkehrschluss aber auch zentrale Kosten. Kosten, die jemand tragen muss. Die meisten Sozialen Netzwerke refinanzieren diese Kosten über Spekulation, den Verkauf der privaten Daten und schließlich Werbung. Werbung hat seitens der Nutzer aber wenig Akzeptanz und wird zunehmend blockiert. Der Verkauf der privaten Daten ist verständlicherweise nicht gewünscht. Und das Bilden einer Finanzierungsblase kann für einen dauerhaften Betrieb nicht sinnvoll sein.

In einem P2P Netzwerk stellt jeder Nutzer einen Teil der Infrastruktur. Abgesehen von den Entwicklungskosten fallen also nur vernachlässigbare Kosten an.

In einem Sozialen Netzwerk (oder gerne auch mehr) auf Basis einer offenen P2P Netzstruktur sehe ich insbesondere folgende Vorteile:

- Schutz der privaten Daten (nur Freunde können Daten missbrauchen).
- Wenn Protokoll und Referenzimplementierung offen und gut durchdacht sind, ist eine Einflussnahme von außen (auch durch die Entwickler) ausgeschlossen.
- Bei Bedarf ist eine anonyme Teilnahme möglich.
- Das Netz kann dynamisch auf Veränderungen der unterliegenden Netztopologien reagieren.


JXTA hatte ich ja bereits erwähnt. Vorteile sehe ich insbesondere darin, dass es ein offenes Protokoll bietet, in dem viele Probleme bereits gelöst sind. Hier gibt es einen ehr praktischen Einblick und hier einen ehr theoretischen (etwas veraltet). Auch wenn die letzte Referenzimplementierung inzwischen über ein Jahr alt ist, so ist die dahinterstehende Technologie doch imho einen Blick wert.

Viele Grüße,
Fancy

 

[tuxedo]

Reines P2P ... Da hatten wir ja bereits erörtert dass das zu komplex für Otto-Normalverbraucher hinter einem DSL-Router oder einem Carrier-NAT ...

 

[Guest2]

Ich wüsste immer noch nicht warum das schwieriger sein sollte als das anklicken eines Links? Wenn auf dem Rechner Java installiert ist, sollte das wunderbar per Webstart gehen. Der Aufwand seitens des Nutzers läge also darin einen Link anzuklicken und einmal auf "Ja" zu klicken (weil die Anwendung signiert sein müsste). Z.B. JXTA unterstützt grundsätzlich NAT-Traversal, sodass auch nichts am Router oder sonst wo konfiguriert werden muss.

Mobile Geräte können als Edge Peer ebenfalls problemlos eingebunden werden. Mehr Aufwand als eine App zu installieren sollte das auch dort nicht sein. Aufgrund der Bandbreite und des Carrier NAT ist es dort eben nicht sinnvoll möglich diese als Rendezvous oder Relays zu betrieben, aber als Edge Peer sehe ich keine Hindernisse.

Wo siehst Du denn ganz konkret Probleme?

Viele Grüße,
Fancy

 

[tuxedo]

Wo siehst Du denn ganz konkret Probleme?

Ich glaub noch nicht dran dass JXTA's grundsätzliches NAT Traversl ohne Infrastruktur problemlos und in 100% der Fälle geht.

 

[Kr0e]

Wäre doch schon cool genug wenn es bei 80% - 90% der Fälle geht!
WebRTC garantiert 100%. Dies geht einfach, in dem bei den Fällen wo es nicht geht auf Proxy-Fallback geswitched wird. WebRTC wird aber noch was dauern...

 

[TheDarkRose]

Ich sehe immer noch nicht den Grund, warum man von 0 anfangen will, anstatt z. B. bei Diaspora mitzuhelfen / zu erweitern? Ruby ist kein Argument dagegen, auch GitHub baut auf Ruby auf und sehet wie erfolgreich es ist. MongoDB ist so eine Sache, aber auch kein großes Hindernis. Ich finde es recht gut, das von mehreren jeweils ein "dezentraler Hub" betrieben wird. Weiß jemand, ob die Protokolle bei Diaspora irgendwo dokumentiert sind? Wenn ja, warum nicht dann so mithelfen, das man eine einfache installierbare Clientsoftware realisiert, die Diaspora um Edge Peers erweitert?

Gesendet von meinem Nexus 7 mit Tapatalk 2

 

[Guest2]

Eben. Sobald erst eine (ausgehende) Verbindung zum Netz steht, können von dort Verbindungsanforderungen abgeholt werden, die dann von innen heraus ganz normal aufgebaut werden. Deshalb gibt es in JXTA Rendezvous Peers, Relays und auch Proxys. Es ist also kein Problem, wenn NAT Traversal in einigen Fällen fehlschlägt, solange genügend Peers von außen erreichbar sind.

Viele Grüße,
Fancy

 

[trääät]

wie gesagt ... ich verfolge das hier schon bewusst und mache mir so meine ernsthaften gedanken ...
wobei ich mich an sich vom "social network" selbst eher distanziere und es mir eher um das darunter liegende de-zentrale netzwerk an sich geht ...

bin halt nicht so der fan dieses ganzen community-hypes ...

um mich aber mal wieder einzugliedern geh ich einfach von meinem post aus abwärts durch

das man mir bei punkt 1 widerspricht akzeptier ich ja noch ... aber das argument mit verschlüsselung ist für mich dann doch nicht so einfach haltbar wie es im ersten moment klingt
ich wollte auch eigentlich eher weniger darauf hinaus ob man mit den daten was anfangen kann oder ob diese für einen sinnvoll sind ... mir ging es eher um den fakt das wenn die daten überhaupt erstmal im netz verteilt wurden man keine kontrolle mehr darüber hat wann wo wie diese daten landen ...

die analogie zu den IE6-usern verstehe ich aber durchaus ...

da finde ich tux post schon eher praktikabel
zwar eine zentrale infrastruktur nutzen ... die aber lediglich für die interkommunikation der einzelnen peers zuständig ist (nach möglichkeit natürlich nicht als relay sondern als rendezvous-punkt) ...
somit läge dann die kontrolle welche daten an wen gesendet werden wirklich beim eigentümer ...
allerdings bringt natürlich auch das wieder nachteile mit sich :
1) gibt man dem falschen die daten hat man ein problem
2) selbst wenn man die daten auch dem richtigen gibt ... so kann man nicht kontrollieren was dieser dann damit am ende macht
3) dürfte es ETWAS nervig werden immer wieder zu sagen : "ja, X darf die daten Y und Z erhalten" ... und der haken "nicht noch mal fragen" käme dann wieder der datenschleuder gleich
und ich denke das halt wirklich dieser eigentlich längst notwendige schritt der eigentlich hätte einer der grundleitgedanken eines solchen systems hätte sein müssen so einfach nicht praktikabel sein dürfte ... und wenn dann nur durch eingetauschten user-komfort so das dieser sich wieder mit X verschiedenen dingen rumärgern muss

dann kam G2 mit der marktwirtschaftlichen seite die jeden "dienst" grundsätzlich in jeder form trifft ...
etwas zentralisiertes bedeutet natürlich das es irgendwo zentrale kosten gibt ...
P2P kann diese natürlich auf die nutzer direkt umlegen anstatt sich durch werbung und andere "machenschaften" das geld zu besorgen was dann über umwege doch wieder vom user bezahlt wird ... allerdings müsste dies dann auch sinnvoll gestaltet werden ...
natürlich kann man entwicklungskosten durch z.b. spenden reinholen und dem user im gegenzug später sagen : ihr tragt mit eurer leistung zum netzwerk bei ... und da ihr diese bezahlen müsst ist der dienst selbst kostenfrei ... und dann könnte man auch auf werbung verzichten und größere arbeiten vorher ankündigen und so von den usern bewusst finanzieren lassen ...
zumindest würde man dann den user selbst nicht verkaufen ...

allerdings muss ich hier entgegenen : alleine die umstellung des zugrunde liegenden "hardware-netzes" ist noch keine lösung für z.b. sicherheit der persönlichen daten ...
ich glaube hier hast du etwas durch ein ander gewürfelt und würdest dann eher wieder in die richtung gehen : daten sind nur dann von einem user einsehbar wenn dieser online ist und sie somit "live" zur verfügung stellen kann ...

was die anbindung von peers angeht die so nicht direkt erreichbar sind (z.b. bei denen selbst STUN fehlschlägt) müsst man sich natürlich auch einen "de-zentralen" gedanken machen ...
da man natürlich "zentrale" server vermeiden will müssten diese rolle halt andere user übernehmen ... aber wie wählt man einen "sicheren" knoten aus ? nur freunde ? vom netzwerk als "sicher" bewertet ? zufall ? es kommt am ende darauf hinaus : egal ob der "relay-knoten" ein freund , ein unbekannter oder der betreiber selbst ist ... man muss zumindest in diesem fall seine daten über andere weiterleiten

was dann noch den einwand angeht sich nicht lieber an einem projekt zu beteiligen das ein ähnliches ziel verfolgt anstatt dieses mit einem eigenen "zu schwächen" ... nun ... ich denke eine antwort darauf kann dir nur TO geben ...

mir persönlich ist es gleich ob ich hier oder sonstwo meine antworten einbringe ... und ich denke nicht mal das die frage grundsätzlich auf java spezifisch bezogen ist sondern eher doch etwas allgemeiner gestellt wurde ... aber hier im java-forum ist das was die meisten hier nun mal am besten können eben java ... und dann ist es sehr wohl ein argument wenn ein anderes projekt mit technologien arbeitet von denen man gerade mal was vom namen her gehört hat ...


ich hoffe ich konnte wenigstens etwas konstruktives einbringen ...
wenn jemand an gewissen punkten was auszusetzen hat bin ich gern bereit mich mit entsprechenden argumenten auseinander zu setzen

 

[Guest2]

Vielleicht wird das mit der Verschlüsselung an einem Beispiel klarer. Nehmen wir die drei Freunde Alice, Bob und Carl:

Alice ist neu und registriert sich im neuen Netzwerk. Dazu füllt Alice ein Formular aus mit allen Daten, die öffentlich einsehbar sein sollen und mit denen Alice von Ihren Freunden gefunden werden will. Ein Nickname und ein Erkennungsmerkmal würden schon reichen. Wenn Alice mag, auch z.B. den Klarnamen und ihr Foto. Die Software von Alice erzeugt lokal zusätzlich einen asymmetrischen Schlüssel. Der öffentliche Teil dieses Schlüssels wird nun von der Software zusammen mit dem öffentlichen Datensatz von Alice im P2P Netz propagiert. Diese Daten werden dort über die dezentralen Indexdienste (z.B. SRDI, shared resource distributed index) eingegliedert und sind dort dauerhaft verfügbar, auch wenn Alice nicht online ist.

Vor Freude will Alice nun direkt ein Foto auf ihrer Pinnwand posten. Nur ihre Freunde Bob und Carl sollen dieses Foto sehen können. Die Software von Alice erzeugt nun zwei unabhängige Pakete, dabei passiert Folgendes:

Alice.1: Es wird ein neuer symmetrischer Schlüssel erzeugt.
Alice.2: Das Foto wird mit dem neuen symmetrischen Schlüssel verschlüsselt.
Alice.3: Das Paket wird im Netzwerk verbreitet (Pakettyp A).

Alice.4: Aus dem SRDI wird der öffentliche Schlüsselteil von Bob geholt.
Alice.5: Es wird ein neues Paket gepackt, dieses enthält: 1. eine individuelle Sequenznummer (hier 0, da es ist die erste Nachricht für Bob ist) und 2. den Fingerprint des ersten Pakets und 3. den symmetrischen Schlüssel aus Alice.1. Alice signiert dieses Paket mit ihrem privaten Schlüsselteil und verschlüsselt es mit dem öffentlichen Schlüsselteil von Bob.
Alice.6: Das Paket wird im Netzwerk verbreitet (Pakettyp B).

Die Software von Alice wiederholt die Schritte Alice.4 bis Alice.6 für Carl. Im Netz befinden sich nun insgesamt drei Pakete:

Pakettyp A: kein Empfänger, kein Absender und kein erkennbarer Inhalt. Aber ein Haltbarkeitsdatum.
Pakettyp B: Bob ist Empfänger, kein erkennbarer Absender, kein erkennbarer Inhalt. Wieder mit Haltbarkeitsdatum.
Pakettyp B: Carl ist Empfänger, kein erkennbarer Absender, kein erkennbarer Inhalt. Wieder mit Haltbarkeitsdatum.

Alle drei Pakete sind über das SRDI auffindbar. Das Netzwerk als Ganzes weiß nun:

1. Alice ist ein neues Mitglied.
2. Bob hat eine Nachricht empfangen.
3. Carl hat eine Nachricht empfangen.

Das Netzwerk weiß NICHT:

1. Das Alice mit Bob und Carl befreundet ist (auch die direkten Peers von Alice können nicht erkennen, ob Alice die Pakete generiert oder nur durchgestellt hat).
2. Das Alice eine Nachricht an Bob oder Carl geschickt hat.
3. Den Inhalt der Nachricht.

Alice kann nun offline gehen. Ihre Pakte sind für die Zeit bis zum Haltbarkeitsdatum im Netz verfügbar.

Bob kommt nun online. Bob ist schon länger angemeldet und nutzt das Netz regelmäßig. Seine Software macht nun Folgendes:

Bob.1: Über das SRDI fragt Bobs Software, ob es neue Nachrichten für ihn gibt.
Bob.2: Bobs Software findet ein Pakettyp B für ihn und holt es aus dem Netzwerk.
Bob.3: Das Paket wird mit dem privaten Schlüsselteil von Bob entschlüsselt und die innenliegende Signatur behauptet das Paket sei von Alice. Der öffentliche Schlüsselteil von Alice wird aus dem SRDI geholt und die Signatur geprüft. Bob bestätigt, dass es sich tatsächlich um die Freundin Alice handelt.
Bob.4.: Der im Paket enthaltene Fingerprint wird genutzt um das zugehörige Paket (Pakettyp A) über das SRDI zu finden. Das Paket wir geholt und mit dem symmetrischen Schlüssel aus Pakettyp B entschlüsselt.
Bob.5: Die Nachricht von Alice wird bei Bob dargestellt.


Lange passiert nun nichts. Das Haltbarkeitsdatum der drei Pakete im Netz ist abgelaufen und keines der Pakete ist mehr im Netz verfügbar. Sie belasten also insbesondere auch nicht mehr das Netz. Alice mag das Netz und postet weiter fleißig Nachrichten auf ihrer Pinnwand.

Carl kommt von seiner Expedition aus der Arktis zurück. Er ist schon länger im Netz aktiv, war aber aufgrund seiner Expedition schon lange nicht mehr online. Seine Software macht nun Folgendes:

Carl.1: Die Software macht dieselben Schritte wie Bob.1 bis Bob.5.
Carl.2: Anhand der Sequenznummer erkennt Carl jedoch das ihn die ersten 42 Nachrichten nicht erreicht haben.
Carl.3: Es wird ein neues Paket (Pakettyp B2) gepackt. Dieses enthält die Bitte, die ersten 42 Nachrichten doch noch einmal im Netz zu propagieren. Diese Nachricht wird mit dem privaten Schlüsselteil von Carl signiert und mit dem öffentlichen Schlüsselteil von Alice verschlüsselt.

Carl geht nun wieder offline. Das Netzwerk weiß, das eine neue Nachricht für Alice vorhanden ist, es weiß aber weder deren Inhalt noch das die Nachricht von Carl kommt.

Alice kommt nun online:

Alice.7: Über das SRDI fragt Alices Software, ob es neue Nachrichten für sie gibt.
Alice.8: Alices Software findet ein Pakettyp B für sie und holt es aus dem Netzwerk.
Alice.9: Das Paket wird entschlüsselt und die innenliegende Signatur behauptet das Paket sei von Carl. Der öffentliche Schlüsselteil von Carl wird aus dem SRDI geholt und die Signatur geprüft. Alice bestätigt, dass es sich tatsächlich um ihren Freund Carl handelt.
Alice.10: Die Software prüft, ob Carl tatsächlich für den Empfang der ersten 42 Nachrichten berechtigt war.
Alice.11: Es wird ein neuer symmetrischer Schlüssel erzeugt, die ersten 42 Nachrichten damit verschlüsselt und in einem Paket verpackt im Netzwerk verbreitet (Pakettyp A).
Alice.12: Wie in Schritt Alice.4 bis Alice.6 wird ein neues Paket (Pakettyp B) für Carl erstellt und verbreitet.

Alice geht offline und Carl kommt online.

Carls Software macht dieselben Schritte wie Bob.1 bis Bob.5. Carls Software stellt alle 42 Nachrichten dar.


Das ganze ist nur ein erster relativ naiver Ansatz, bei dem vieles noch durchdacht werden müsste. Aber auch so sollte die Privatsphäre von Alice, Bob und Carl sicher sein. Wenn die Daten von Alice missbraucht werden, dann kann es eigentlich nur Bob oder Carl gewesen sein. Dann liegt der Fehler aber nicht im Netz, sondern an den Freunden von Alice.

Viele Grüße,
Fancy

 

[TheDarkRose]

Also das Prinzip klingt schon mal recht gut durchdacht. Sicher sind noch viele Kleinigkeiten zu beachten, aber der Ansatz ist interessant. Bin gespannt auf deine weitere Ausarbeitung, vielleicht kann ich auch an der ein oder anderen Komponente mithelfen

 

[Lumaraf]

Gundsätzlich klingt das schonmal ganz gut. Aber was passiert wenn der Netzwerkknoten denen man Daten zur Speicherung geschickt hat für längere Zeit offline ist. Das Netzwerk müßte mit einer ziemlich hohen Redundanz der Daten arbeiten und auch regelmäßig neue Kopien der Daten erstellen um die Daten länger als ein paar Stunden verfügbar zu halten. Das erhöht dann allerdings für alle Teilnehmer die notwendige Bandbreite und auch die Menge an Speicherplatz die sie zur Verfügung stellen müßen. Außerdem führt das dazu das man beim Verbinden bei mehr Netzwerkknoten erstmal nach Daten für sich suchen muß.

Eine Möglichkeit um das Problem zu lösen wäre z.b. die Speicherung einem speziellen Speichernetz zu überlassen. Das wäre dann einfach ein P2P-Netz das nur aus Servern besteht. Einen Server sollte jeder betreiben können der genügend Speicherplatz und Bandbreite zur Verfügung stellen kann und auch für eine Ordentliche Uptime sorgen kann. Die Struktur würde es auch deutlich einfacher machen über eine mobile Verbindung am Netzwerk teilzunehmen.

 

[Marco13]

Habe nicht alles gelesen, irgendwo zwischendurch haben meine Kenntnisse der Möglichkeiten bzgl. Techniken und Infrastrukturen aufgehört und vermutlich sind DAS genau die interessantesten Beiträge, weil sie tendenziell eher von Leuten kommen, die genauer wissen, wovon sie reden, als ich, aber ... irgendwann am Anfang dachte ich, dass die Verwaltung der Profile ähnlich ablaufen könnte/sollte wie die Verwaltung von Repositories auf GitHub: Jeder speichert sich lokal eine Kopie der Profile seiner ""Freunde"". Wenn man eins der Profile ansehen will (oder beim Programmstart) wird nachgeschaut, ob es noch aktuell ist, und ggf. aktualisiert, falls der ""Freund"" auch online ist, oder einer der anderen ""Freunde"" online ist und ein aktuelleres des bestagten ""Freundes"" Profil hat. Die Sicherheit (im Sinne von Datenschutz, und der Möglichkeit, dafür zu sorgen, dass das Profil oder Teile davon nicht mehr gelesen werden können) wäre sicher ein wichtiger Punkt. Ich glaube, dass es technisch schwierig (aber ein unique selling point) sein könnte, wenn die bei Freunden lokal gespeicherten Profile nach einer gewissen Zeit unlesbar werden, wenn sie nicht zwischendrin "bestätigt" werden (dadurch, dass man online geht, und öffentlich mitteilt "Ja, mein Profil gilt noch"). Ich glaube, das ist sowas, was Fancy auch angedeutet hat, aber ... das war einer dieser Beiträge....

 

[trääät]

ich hätte da aber immer noch ne anmerkung zur verteilung der daten im netz ...

@G2 : was du mit "im netz propagieren" meinst ist mir durchaus bewusst ... die frage ist aber WO ? du sprichst zwar von einem zentralen index ... aber nicht davon wie man nun die daten wirklich speichern sollte / könnte ...
klar könnte man die daten einfach wild durchs netz jagen und auf irgendwelchen anderen rechner speichern ... aber da diese auch nicht dauer-on sind müsste wie angesprochen mit redundanz gearbeitet werden ...

auch finde ich den ansatz für carl sehr wage ... denn dafür müsste alice system grundsätzlich ALLES speichern bis alles im netz an alle verteilt wurde ... und somit die daten auf anderen systemen liegen ... ansonsten wächst doch alleine der cache bei alice der nur für zuständig ist daten die während ihres TTL nicht den empfänger erreicht haben erneut zur verfügung zu stellen ... und auch die caches von bob und carl werden mit der zeit immer voller da sie ja sicher auch die daten von alice länger nutzen wollen und daher lokal kopieren ...

was daraus folgt lässt sich einfach erklären : je größer das netz wird desto mehr muss jeder einzelne an x-fachem speicher dafür einräumen nur um 1) seinen freunden daten zur verfügung zu stellen und 2) daten von freunden auch länger zu behalten ...

und ich denke das hier schluss mit der idee sein dürfte und es einfacher umsetzbar und vor allem für den einzelnen user "bequemer" sein sollte wenn eben die daten auf einem zentralen server gespeichert werden und halt nur dessen plattkapazitäten regelmäßig erhöt werden müssen ...

denn selbst wenn wir das kleine beispiel mit alice bob und carl nur um david erweitern braucht david platz um 1) seine eigenen daten zu cachen und 2) 3x platz für die daten von alice bob und carl ... und bei alice bob und carl im gegenzug wächst der cache ebenfalls um mindestens die daten die für david bestimmt sind und von ihm kommen ...

zusätzlich halt noch die redundanz und die frage : wo die daten "zwischenpuffern" bis der empfänger sie abholt ...

und all diesen doch wirklich enormen speicherplatz und die unglaubliche bandbreite kann nicht von jedem user gestellt werden ... womit es irgendwann "schwerpunkte" geben wird die z.b. ne 200'000er synchron-leitung haben und daran mehrere "server" mit je einigen terabytes hängen ...

und hier greift wieder die sicherheit : es geht nicht darum das die daten für 3te nicht "lesbar" sind ... sondern grundsätzlich darum das sie zumindest nach dem model von G2 erstmal im netz verteilt werden ... und wenn man da dann genug rechen-power dranhängt kann man den cache auch irgendwann komplett entschlüsseln ...

das sind alles dinge bei denen ich denke (wie schon mal erwähnt) : als theoretisches problem sicher hoch-interessant ... aber praktisch heute leider noch nicht ganz so einfach umsetzbar ... dafür braucht es mindestens flächendeckend hochgeschwindigkeits-netzzugäng die auch eine hohe upstream-breite haben (am besten synchron-leitungen) und große speicher-reserven ...

 

[Guest2]

Eine Möglichkeit um das Problem zu lösen wäre z.b. die Speicherung einem speziellen Speichernetz zu überlassen. Das wäre dann einfach ein P2P-Netz das nur aus Servern besteht.

Imho sollte idealerweise das "Speichernetz" ein Teil des "normalen" P2P Netzes sein. Bei der Entwicklung von JXTA wurden imho große Clustersysteme eingesetzt, um das Verhalten von Millionen von Peers simulieren zu können. Die dabei entstandenen Algorithmen bestimmen dynamisch die Rolle des einzelnen Peers im Netz. Zumindest sollte das so sein, ich weiß nicht, wie Feature Complete oder Bugfrei die aktuelle Referenzimplementierung ist.

Wenn man eins der Profile ansehen will (oder beim Programmstart) wird nachgeschaut, ob es noch aktuell ist, und ggf. aktualisiert, falls der ""Freund"" auch online ist, oder einer der anderen ""Freunde"" online ist und ein aktuelleres des bestagten ""Freundes"" Profil hat.

Ja, in gewissem Masse würde das so wohl Funktionieren. Allerdings sind die Ansprüche der Nutzer inzwischen imho zu groß. Ich kenne das z.B. so, dass eine kurzfristige Verabredung per Facebook Nachricht organisiert wird. Nicht per Email, SMS oder gar Telefon. Wenn eine Nachricht erst von Freund zu Freund "hoppeln" muss, ist das nicht zuverlässig genug oder schlicht zu langsam. Deshalb muss eine neue Nachricht imho massiv verfügbar gehalten werden. Je älter die Nachricht wird, je weiter könnte man wohl die Redundanz reduzieren.

Ich glaube, dass es technisch schwierig (aber ein unique selling point) sein könnte, wenn die bei Freunden lokal gespeicherten Profile nach einer gewissen Zeit unlesbar werden, wenn sie nicht zwischendrin "bestätigt" werden (dadurch, dass man online geht, und öffentlich mitteilt "Ja, mein Profil gilt noch"). Ich glaube, das ist sowas, was Fancy auch angedeutet hat, aber ... das war einer dieser Beiträge....

Ja, so was wäre in der Tat gut. Aber imho nicht wasserdicht machbar. Mein Beispiel bezog sich darauf, was passiert, wenn die Nachricht noch nicht bei Carl angekommen ist. Ist sie das aber erstmal, liegt sie auch im Verantwortungsbereich von Carl. Natürlich kann man die Software so schreiben, dass die entsprechende Nachricht auch lokal bei Carl gelöscht wird, aber nichts hindert Carl daran die Nachricht extern zu speichern oder gar seinen Client so zu manipulieren das nicht gelöscht wird. Und sind wir ehrlich, wenn Alice im Suff ein Bild postet, in dem sie sich nackt auf dem Wohnzimmertisch rekelt, dann nutzen Bob und Carl das vielleicht als neuen Desktophintergrund, aber löschen werden sie es nicht!

In den Medien taucht das Thema immer mal wieder gerne unter "Recht auf vergessen" oder "Digitaler Radiergummi" auf. Sinnvolle Konzepte sind mir dazu aber noch nicht begegnet.

Imho lassen sich soziale Probleme nicht mit technischen Mitteln lösen.

was du mit "im netz propagieren" meinst ist mir durchaus bewusst ... die frage ist aber WO ? du sprichst zwar von einem zentralen index ... aber nicht davon wie man nun die daten wirklich speichern sollte / könnte ...
klar könnte man die daten einfach wild durchs netz jagen und auf irgendwelchen anderen rechner speichern ... aber da diese auch nicht dauer-on sind müsste wie angesprochen mit redundanz gearbeitet werden ...

Ja genau, Redundanz wird benötigt und zwar sogar massiv! Aktuelle Nachrichten müssen schnell und überall verfügbar sein, sonnst würde das Netz imho keine Akzeptanz seitens der Nutzer finden. Das "wo" ergibt sich aus dem dezentralen Index. Aktuell dürften die meisten Algorithmen dazu wohl Varianten von DHT (Distributed Hash Table) sein. Bei JXTA ist es eben die erwähnte Ausprägung als SRDI.

1) seinen freunden daten zur verfügung zu stellen und 2) daten von freunden auch länger zu behalten ...

Das liegt in der Natur der Sache. Jeder speichert sein eigenes Profil und die Profile seiner Freunde, soweit er eben möchte. Das sollte aber kein Problem darstellen. Die meisten Nachrichten auf Facebook sind nur wenige Byte groß. Das Einzige was einschlägt, sind Fotos und Videos. Alice würde ihre eigenen Fotos, Videos und Inhalte aber wohl sowieso speichern. Die Daten ihrer Freunde sind vom reinen Volumen auch nicht wirklich relevant. Würde ich z.B. die Profile und Nachrichten meiner Facebook "Freunde" speichern, wäre das immer noch deutlich weniger als z.B. das Cache Verzeichnis meines Emailclients.

und ich denke das hier schluss mit der idee sein dürfte und es einfacher umsetzbar und vor allem für den einzelnen user "bequemer" sein sollte wenn eben die daten auf einem zentralen server gespeichert werden und halt nur dessen plattkapazitäten regelmäßig erhöt werden müssen ...

Zentrale Systeme sind nicht nur teuer, sie skalieren auch nur relativ schwer. Bei einem Server wäre vermutlich bei spätestens 1000 Nutzern Schluss. Als unrealistischer Facebook Vergleich: Facebook hat täglich 2.5 Milliarden Inhalte, 2.7 Milliarden Likes und 300 Millionen Fotos mit einem Datenvolumen von 500 Terabyte (Quelle). Dazu nutzt Facebook vermutlich etwa 180 000 Server und verbraucht 532 Millionen kWh pro Jahr (Quelle). Bedient werden damit etwa 900 Millionen Nutzer. Ich halte ein P2P Netz mit 900 Millionen Peers für effizienter und deutlich einfacher zu finanzieren. (Die Last pro Peer wäre wohl gering).

und hier greift wieder die sicherheit : es geht nicht darum das die daten für 3te nicht "lesbar" sind ... sondern grundsätzlich darum das sie zumindest nach dem model von G2 erstmal im netz verteilt werden ... und wenn man da dann genug rechen-power dranhängt kann man den cache auch irgendwann komplett entschlüsseln ...

Wenn die Verschlüsselung wirklich mal fallen sollte, gibt es aber noch ganz andere Probleme. Es gibt Leute, die behaupten, dass wenn aktuelle Verschlüsselungsverfahren tatsächlich plötzlich unwirksam würden, würde die Welt wie wir sie kennen untergehen. Auf jeden Fall hören dann Geld und Banken erstmal auf zu existieren.


Viele Grüße,
Fancy

 

[trääät]

mir sind de-zentrale index-systeme wie DHT durchaus vertraut ... jedoch ermöglichen diese nur das auffinden der quelle ... WAS aber nun klar als speicher in frage kommt und WO WELCHE daten landen ... darüber schweigst du dich leider immer noch aus ...
wenn es so einfach ist dann nenne doch mal ein praktisches beispiel ...
das man persönliche daten speichert ist klar ... allerdings dann meist in einer form die nicht unbedingt dauerhaft am netz hängt ... die also so nicht dauerhaft verfügbar ist ...
"linkt" man nun seine eigenen daten lediglich so könnte man die daten nicht lesen wenn diese z.b. auf einer zu diesem zeitpunkt nicht angeschlossenen externen platte liegen ... > cachen auf der system-platte ... womit man schon mal selbst seine eigenen daten dupliziert ... und glaub mir ... diese riesen zahlen sind für mich duchaus realistisch ...
in meinem system finden sich 2 80er 1 160er und ne 500er platte ... plus 80er extern macht das gesamtplatz von rund 900GB abzüglich der rechenfehler dezimal<->binär
normale 0-8-15 user die sich mal eben so n aldi-pc mit ner 2TB platte holen haben diesen platz meist als eine große partition ... was natürlich bei mir auch möglich wäre aber ich den vorteil von seperaten platten vorziehe ...
nun stell dir mal vor ich krach mein rechner voll und lager aus ... will aber trotzdem die daten verfügbar halten ... und damit eben das geht müsste ich die daten von der auslagerung im system cachen > kein plattenplatz und zusätzlich das system damit flooden ...
und dann kommt noch der anteil an platz hinzu dem ich den netzwerkstelle ... um mal eine halbwegs praktikable antwort auf die frage zu geben : WO im netz propagierte daten nun wirklich speichern ?


zu deinem FB-beispiel : es mag sicher richtig sein das man mit 900 millionen peers ein gewaltiges netz aufbauen könnte ... allerdings nur wenn jeder dieser peers die leistung eines servers bringt und auch mit einer vergleichbaren bandbreite ans netz angeklemmt ist ...
was bringen mir 900 millionen peers wenn jeder einzelne nicht mal über einen upload von 1MBit/s verfügt ? da bringt es nichts wenn man mit 50MBit/s runterladen kann ...
und genau hier setz mein "es ist bequemer" ein da server in der regel mit 100MBit/s an ein 8,1GBit/s backbone angebunden sind ... und damit alleine was den upstream und die rechenpower angeht locker mehrere client-system ersetzen könnten ...


und zum knacken von etablierten crypto-verfahren : mit der richtigen technik ... einer großen anzahl und genügend zeit ist NICHTS sicher ... nicht mal RSA8192 ums ganz derb zu übertreiben ... zu mal eh viele dinge im netz mit symetrischen schlüsseln irgendwo zwischen 128 und 256 bit ausgetauscht werden ... und lediglich die schlüssel selbst durch solch hoch-komplexe dinge wie RSA ... ergibt sich daraus ein weiterer vorteil um "einzubrechen" ...
und jemand der es will schafft es auch ...


an sich finde ich deine posts ja gar nicht mal so verkehrt ... allerdings verweist du immer auf etwas und gehst scheinbar davon aus das das jeder kennt und sich damit befasst ...
da muss ich leider entgegen : JXTA sagt mir NICHTS ... warum also konfrontierst du mich damit ? gehts nicht auch etwas allgemeiner ? einfach mal grob beschreiben anstatt gleich auf spezifische "referenz-implementierungen" zu verweisen ?
die mühe mach ich mir nicht ...

auch merkt man das von dir eher nur sehr viel theoretisches kommt ... aber praktisch nur schwer umsetzbar ist und du auf dierekt frage mit wieterer theorie ausweichst ...

ist mir schon am letzten post aufgefallen : theoretisch klingt das alles machbar ... aber dann setzt das mal praktisch um ...
bilde doch mal bitte in einem netz mit eben nur 3 peers einen de-zentralen index und "speicherkapazität im netz" wenn du nirgends darauf eingehst wie du wo welche daten genau speichern würdest ... und damit meine ich physisch auf den platten der verbundenen peers ...

ich wiederhole mich noch mal : theoretisch klingt das alles super ... und wenn man es auf ein paar hunderttausende rausskaliert mag es auch praktisch machbar sein ... aber ich persönlich hätte keien idee wie ich sowas praktisch implementieren könnte ...und so lange ich da auch nichts funktionierendes sehe ist es für mich auch nur theorie

 

[Kr0e]

und zum knacken von etablierten crypto-verfahren : mit der richtigen technik ... einer großen anzahl und genügend zeit ist NICHTS sicher ... nicht mal RSA8192 ums ganz derb zu übertreiben ... zu mal eh viele dinge im netz mit symetrischen schlüsseln irgendwo zwischen 128 und 256 bit ausgetauscht werden ... und lediglich die schlüssel selbst durch solch hoch-komplexe dinge wie RSA ... ergibt sich daraus ein weiterer vorteil um "einzubrechen" ...
und jemand der es will schafft es auch ...

Ich weiß nicht genau, auf welche Verfahren zum knacken du anspielst oder welchen Crypto-Background du hast. Aber um RSA8192 zu knacken via Bruteforce.. naja have fun. Via Mathematischen Primzahlzerlegungs-Mechanismen ist bestimmt noch einiges rauszuholen und ich will auch nicht bestreiten, dass NSA etc. noch ganz andere Verfahren haben, aber RSA8192 IST sicher.

Meistens sind die Programme, die diesen Algo nutzen nicht sicher und bieten Angriffsstellen aber aus theoretischer Sicht ist RSA mit langen Schlüssen praktisch nicht zu knacken. Ich will jetzt hier mal ggf. Rechenleistung eines theoretischen Quantenrechners außer Acht lassen.

Falls du dennoch davon überzeugt bist, dass es so einfach zu knacken sei, wäre ich interessiert (aus akademischer Sicht) wie das zu bewerkstelligen ist. Andersfalls würde ich solche Aussagen als Trolling abtun

PS: Was siehst du als genug Zeit ab ? 1000 Jahre ??

 

[trääät]

nun ... es ist richtig das gerade RSA mit genügend langem schlüssel eines der sichersten crypto-verfahren ist da es nun mal auf einem mathematischen problem beruht was selbst mit moderner rechenleistung nur schwer zu lösen ist ...

und eigentlich trifft es auch auf andere verfahren zu : sind die schlüssel und block-größen ausreichend groß und die zahl der crypto-runden ebenfalls hoch sind auch diese gegen angriffe besser geschützt ...

aber ich rede nicht mal von der leistung eines theoretischen "quantencomputers" ... und auch nicht von 1000 jahren ... sondern z.b. von 900 millionen peers in einem netzwerk von denen jeder einem heutig mittel von irgendwas in richtung multi-core-cpu mit um die 2 bis 3 GHz taktfrequenz entspricht ... und dann dürfte es schon in noch absehbarer zeit machbar sein ...

 

[tuxedo]

@träät

Stimme dir zu. Das Hauptproblem bei der P2P Sache ist die meist asynchrone Geschwindigkeit der angebundenen Benutzer. Auch wenn die wenigsten 2TB an Bilder mit ihren Freunden teilen. Bei den meisten sind es wohl deutlich <100MB (okay, mit der Zeit wird das wohl mehr werden).

P2P skaliert zwar theoretisch besser als ein zentrales System. Aber aus meinene Erfahrungen mit P2P Netzen (angefangen bei den frühen edonkey-Netzen bis hin zu den torrent-Netzen): Die skalieren auch nicht wirklich gut. Die Performance geht da schon massiv in die Knie wenn du eine Verbindung vom einen Ende zum anderen Ende benötigst. Schuld daran wie immer: Die Asynchrone anbindung.

Finde ein zentrales Rückgrat stabiler und performance-mäßig wohl besser. Wenn auch gleich aufwendiger und teurer. Aber da diese ganze Diskussion hier eh schon ins "theoretische" abgedrifttet ist, passt das ja ganz gut. Denn niemand wird sich aus diesen Reihen wohl den Schuh anziehen, und für den Anfang mal ein halbes Dutzend Server hinstellen, und dann, wenns alles glatt läuft (wovon nicht auszugehen ist, denn FB hat es sich IMHO noch nicht genug mit seinen Benutzern versch***en), weitere hundert bis mehrere tausend Server weltweit nachziehen.

Ich denke nicht dass FB hauptsächlich vom Verkauf der persönlichen Daten lebt. Da kommt ja auch noch Werbung und das ganze Geraffeln mit den Lizenzen für die Anbindung externer "Dienste" (z.B. das Zynga-Gaming-Geraffel) hinzu. Von daher wären die Kosten wohl das kleinere Problem. EInnahmequellen gäbe es wohl genug.

- Alex

 

[JohannisderKaeufer]

Warum also das ganze nicht komplett mobil auslegen? Gibt's hier NAT-Probleme? Weiß das einer?

Ja. Hängt aber vom Land und Anbieter ab. In der Regel bekommst du mobil keine eigene IP, sondern bist hinter einer NAT vom Provider und teilst dir die IP. Argh, darauf wurde schon hingewiesen.


Man kann von Sascha Lobo halten was man will. Aber auf der Republica 2012 hat er ein interessanten Vortrag zum Thema gehalten und 2012 zum Jahr des Blogs ausgerufen.

Sascha Lobo: Überraschungsvortrag - YouTube