Der Schockwellenreiter Rotating Header Image

Entwurf eines P2P Social Networks

»The Internet is great because it is decentralized. If you centralize it, it stops being the Internet.« — (Dave Winer)

Warum P2P?

Die großen sozialen Netze von Twitter über Facebook bis Google+ kranken an ihrer zentralen Struktur. Dave Winer hatte sie einmal mit Datensilos verglichen, in denen der Nutzer zwar seine Daten hineinsteckt, aber sie nicht mehr hinaus­bekommt. Das heißt, der Nutzer ist nicht mehr Herr seiner Daten, wenn Facebook zum Beispiel beschließt, dichtzumachen, oder Google meint, ihn wegen eines Pseudonyms von Google+ auszuschließen, ist alles weg.

Das ist zum Beispiel auch der Grund, warum mein Hauptpublikationstool immer noch mein (selbstgehostetes) Blog ist. Hier gehören mir meine Daten, ich entscheide, was mit ihnen geschieht und wenn mein Provider dicht macht, habe ich (hoffentlich) noch ein Backup und kann woanders alles relativ problemlos neu aufsetzen.

Auf der anderen Seite fehlen (m)einem Blog natürlich viele der netten Dinge, die den Sozialen Netzwerken zueigen sind: Ich kann keine Freundeskreise anlegen, deren Nachrichten verfolgen und kommentieren oder einfach mal einen Knopf drücken, der »Gefällt mir« sagt.

Das war also der Ausgangspunkt meiner Überlegungen: Wie muß ein soziales Netzwerk aussehen, in dem der Nutzer immer und zu jedem Zeitpunkt Herr seiner Daten bleibt, das Kommentare und Like-Buttons ermöglicht und das notfalls sogar auf minimalem Webspace mit statischen Seiten funktioniert?

Webserver auf dem Desktop

Wir waren an solch einer Lösung schon einmal sehr nahe dran. Mit Dave Winers Software Radio Userland feierte schon im Jahre 2000 die Idee eines Webservers auf dem Desktop als Kommadozentrale für alle Webaktivitäten ihren Einstand. Der User bloggte dort und die Software schrieb via FTP (oder XML-RPC) statische Seiten auf einen Webspace der Wahl.

Nun füllt man sein Weblog nicht unbedingt nur von einem Rechner aus. Ich habe zum Beispiel über Jahre den Schockwellenreiter mithilfe von Frontier und einer selbstgeschriebenen, vereinfachten Version von Radio Userland von drei verschiedenen Rechner aus gefüttert. Anfangs hatte ich dazu die Datenbasis (die root-Datenbank) immer auf einem USB-Stick mit mir herumgetragen, nachdem ich aber mehrmals durcheinandergekommen war, weil ich bei der letzten Sitzung vergessen hatte, die aktuelle Version der Datenbank wieder zurück auf den Stick zu überspielen, war mir klar, daß dies keine dauerhafte Lösung sein konnte. Da kam mir die Dropbox gerade recht.

Datenbasis in der Cloud

Denn die Datenbasis in die Cloud – in meinem Falle in die Tropfenschachtel – zu verlegen, bedeutet ja nicht, seine Daten wegzugeben. Sie liegen ja weiterhin, nun aber »ordentlich« synchronisiert, auf meinen Rechnern und sind auch offline nutzbar. Der Sicherheitsaspekt spielt keine besondere Rolle, da es ja sowieso nur Daten sind, die ich für eine Veröffentlichung vorgesehen habe.

Ein Nachteil bei der Dropbox und ähnlichen Lösungen ist sicher, daß Konflikte auftreten können, wenn mehr als ein Nutzer gleichzeitig auf die Daten zugreift. Ich gehe allerdings davon aus, daß die Mehrheit der Nutzer des von mir angedachten sozialen P2P-Netzwerks Einzelnutzer sind. Wenn dies nicht der Fall ist, muß man an Stelle der Dropbox vielleicht ein öffentliches Repositorium wie zum Beispiel GitHub verwenden. Das macht die Sache zwar ein wenig komplizierter, löst aber das Problem der Zugriffskonflikte.

RSS als Nachrichtenstrom

Radio Userland hatte aber noch etwas, was es in die Nähe heutiger sozialer Netze rückt: Es hatte einen integrierten RSS-Feed-Reader, der nicht – wie zum Beispiel Googles Reader – die einkommenden Feeds nach den Quellen gruppierte, sonder sie als fortlaufenden zeitlichen Nachrichtenstrom anzeigte, ähnlich wie heute auch Google+, Facebook oder Twitter.

Das wäre die erste Komponente eines P2P-Netzes. Ich abboniere die RSS-Feeds meiner »Freunde« und wie auf Twitter, Facebook oder Google+ rauschen deren Nachrichten als River of News (Winer) an mir vorbei.

Publishing-Interface

Die drei Hauptseiten des User-Interface

Die zweite Komponente ist natürlich ein Publishing Interface. Das sieht erst einmal kaum anders aus, als die gewohnten Weblog-Eingabmasken. Und das Einzige, was es erst einmal herausschreiben muß, ist nichts anderes als einen RSS oder Atom-Feed, den die Software automatisch auf einen Webspace meiner Wahl der Öffentlichkeit zugänglich macht.

Natürlich ist mehr möglich: Zum einen könnte die Software – wie damals schon Radio Userland – alle oder auch nur einen Teil der Beiträge als Weblog mit statischen Seiten herausschreiben. Aber auch ein automatisches Füttern von Weblog-Software via API oder XML-RPC wäre möglich. Und es wäre dann völlig egal, ob es ein selbstgehostetes WordPress-Blog ist oder ich ein Blog bei einem Bloghoster wie Blogger oder Typepad vollschreibe. Die Originaldaten liegen ja weiterhin auf meinem Desktop, das Blog ist nur ein zusätzlicher Distributionskanal.

Und last but not least kann ich auch die vielgeschmähten sozialen Netzwerke via ihrer APIs damit bedenken. Und ich muß diese ja nicht mit all meinen Ergüssen vollmüllen. So bin ich zum Beispiel Teil einer netten Agility-Community auf Facebook und die Software sollte es so einrichten können, daß alle Beiträge, die mit Agility getagged sind, automatisch als Crossposting auf Facebook landen.

Das setzt natürlich einiges an Konfiguration voraus, die man nicht bei jedem Post vornehmen möchte. Daher sollte es eine Default-Konfiguration geben, in der der Nutzer festlegt, welche Sozialen Netze er bedienen möchte (im Minimalfall schreibt die Software eben nur einen RSS-Feed heraus), welche wie getaggten Beiträge in welchen Netzen landen und so weiter. Aber natürlich sollte der Nutzer die Möglichkeit haben, diese Konfiguration bei jedem Post überschreiben zu können.

Und so schweben mir auch zwei parallele Nutzerschnittstellen für die Postings vor: Eine einfache, die ähnlich den bisherigen sozialen Netzen ein simples und schnelles Posten erlaubt und die – weil der Nutzer das so gewohnt ist – über dem Nachrichtenstrom schwebt.

Und ein mehr elaboriertes Interface, das ähnlich der »Artikel erstellen«-Seite von WordPress, dem Nutzer mehr Möglichkeiten gibt, in die Konfiguration einzugreifen und diese für diesen einen Artikel anzupassen, Tags oder Kategorien zu vergeben und die Publikationspfade zu beeinflussen.

Schließlich sollte es natürlich noch eine Seite geben, die nur meine eigenen Aktivitäten anzeigt, ähnlich der Pinnwand von Facebook. Denn gerade, wenn ich mich entschließe, kein Blog zu führen, sondern »nur« einen RSS- oder Atom-Feed herauszuschreiben und vielleicht auch noch Facebook zu füttern, wäre diese Seite eine Art Blogersatz oder mehr ein Tagebuch meiner Aktivitäten nur für mich.

Und auch über dieser Seite sollte es – wie bei Facebook – die vereinfachte Eingabemaske geben. Denn das ist eines der Dinge, die mich bei Google+ regelmäßig ärgern: Ich kann Eingaben nur von der Startseite aus tätigen, nicht aber von meiner Profilseite.

Kommentare und »Gefällt mir«-Knöpfe

Bleibt nur noch das Problem der Kommentare und des »Like-Buttons«. Doch wenn man die Idee des RSS- oder Atom-Feeds konsequent zu Ende denkt, bietet sich auch dieser hier als Lösung an. Obwohl es sicher möglich ist, bestehende, wenn auch selten genutzte Tags der Feeds umzudefinieren, um das Erwünschte zu erreichen, schlage ich – einfach weil es sauberer ist – eine Namespace-Erweiterung (ähnlich der iTunes-Erweiterungen) vor: Für die Kommentare werden (mindestens) zwei zusätzliche Tags benötigt. Einmal einen <comment_title>-Tag und einen <comment_url>-Tag. Und dann bekommt jeder einzelne Feedbeitrag auf der Startseite einen Kommentar-Knopf, der ein Textfeld öffnet, in dem der Kommentar eingetippt werden kann.

Und erst einmal geht dieser Kommentar dann – wie jeder gewöhnliche Beitrag auch – als RSS-Feed auf die Reise. Nur, daß er die beiden vorgeschlagenen zusätzlichen Tags enthält. Was der jeweilige Reader nach Erhalt damit anstellt, bleibt ihm überlassen: Entwender er reiht sie – ähnlich Twitter – wie jeden anderen Beitrag auch in den Zeitstrom ein oder er behandelt sie wie Facebook oder Google+, das heißt, die Kommentare werden als Threads den jeweiligen Beiträgen zugeordnet.

Im zweiten Fall können die Kommentare dann natürlich auch beim nächsten Herausschreiben des Blogs auf diesem angezeigt werden – und das, ohne daß auf dem Server des Hosters irgendein Skript oder ähnliches laufen müßte.

Analog kann mit dem »Gefällt mir«-Knopf verfahren werden. Auch beim Einsatz dieses Elements müssen (mindestens) zwei zusätzliche Tags für den Feed bereitgestellt werden: Einmal einen <like_url>- und dann natürlich auch einen <like_title>-Tag. Und ob der lesende Server dann stolz die Anzahl der »Likes« zählt und anzeigt oder ob er es einfach ignoriert, bleibt wieder ihm überlassen.

Und ebenso geht das »Teilen« vonstatten: Ein »Share«-Button zu jedem Feedeintrag, ein zusätzlicher <share_url>- und ein <share_title>-Tag im Feed des Nutzers und dann wird der Beitrag erneut im Feed des Nutzers publiziert.

Share und Like in Googles Feedreader

Das alles erfordert ein gewisses Umdenken. Kommentieren, Teilen oder die Zustimmung per Knopfdruck findet nicht mehr auf dem Server des Autors statt, sondern im Feedreader des Lesers. Aber daß dies funktionieren kann, hat uns Googles Feedreader ja vorgemacht.

Auf den Schultern eines Riesen

Natürlich ist dies nicht alles auf meinem Mist gewachsen. Dave Winer, der seine Frontier-Fork, den OPML-Editor, bis an die Schmerzgrenze ausreizt, hat vieles von dem vorgedacht: Es fing ja schon mit Radio Userland an, dann teilte ich seine Bedenken gegenüber den Datensilos der Sozialen Netzwerke. Von ihm stammt der River of News, die Idee, RSS als Publishing-Format zu nutzen (was bei ihm, der sich ja gerne als »the father of RSS« bezeichnen läßt, auch nicht wundert) und mit Radio2 hat er diese Idee – auf Basis des OPML-Editors – auch weitgehend umgesetzt.

Allerdings geht Winer von einer Community aus, die sich weitesgehend um seine Software dreht, den Gedanken eines konsequenten Peer-to-Peer-Netzes hat er nicht zuende gedacht. Dennoch verdanke ich ihm viel und möchte das daher nicht unerwähnt lassen.

Ich bin sicher, daß man mit Winers OPML-Editor sehr schnell einen Prototypen dieser Ideen zusammenbasteln könnte – Winer hat zwar das auf meine Anregung aufgenommene Static Site Framework wieder aus der Standard-Distribution des OPML-Editors entfernt (warum eigentlich?), aber das läßt sich sicher leicht nachrüsten. Aber natürlich geht das mit nahezu jedem anderen Stück Web-Framework auch: Ob Django, Ruby on Rails, irgendeine PHP-Anwendung unter MAMP oder XAMPP oder ein aufgebohrtes DokuWiki … alles, was irgendwie eine Serverumgebung auf dem Desktop realisiert und RSS-Feed herausschreiben kann, eignet sich als Grundlage.

Und unter Umständen kann man – wie ich weiter unten ausgeführt habe – sogar auf die Server-Umgebung verzichten. Das einzige, was benötigt wird, ist ein Stück Software, das mit RSS- und ATOM-Feeds (inklusive der von mir vorgeschlagenen minimalen Ergänzungen) umgehen kann. Was das für eine Software ist und auf welchem Rechner unter welchem Betriebssystem sie läuft, ist zum Funktionieren dieses P2P Social Networks völlig egal.

Zusammenfassung

Die von mir vorgeschlagene Lösung hat den Vorteil, daß sie einmal eine konsequente Trennung von Redaktionsserver (das ist in diesem Fall der Server auf dem Desktop) und Produktionsserver – im Falle der minimalistischsten Lösung ist dies der Server, auf dem der RSS- oder Atom-Feed liegt – vornimmt. Dabei braucht der Redaktionsserver nicht einmal unbedingt ein wirklicher Server zu sein. Ich bin mir sicher, daß Elisp-Bastler es auch schaffen, zum Beispiel den Org-mode des Emacs so aufzubohren, daß er als »Redaktionsserver« einsetzbar ist. Lediglich das Einfahren des RSS-Feeds müßte dann vermutlich manuell vom Nutzer angestoßen werden.

Zum zweiten – und das ist mir das Wichtigste – behält der Nutzer die volle Kontrolle über seine Beiträge und Dateien. Artikel, Bilder, Videos … all dies liegt und bleibt auf dem Desktop des Nutzers, die jeweiligen Clients erhalten bestenfalls eine Kopie. Natürlich bleibt es dem Nutzer unbenommen, falls zum Beispiel sein Hoster nicht genug oder zu teuren Speicherplatz zur Verfügung stellt, auch Flickr, YouTube, Picasas Web Album oder andere Dienste zu nutzen und seine Multimedia-Dateien darüber einzubinden. Die Software sollte dies ermöglichen, in dem sie zum Beispiel alle Bilder, die in einem dafür vorgesehenen Ordner liegen, zu Flickr hochlädt; aber sie sollte trotzdem eine Kopie der Daten auf dem Desktop behalten.

Und auch das Publizieren in der Cloud bereitet so keine Kopfschmerzen mehr. Warum sollte man nicht anstelle eines »normalen« ISP wie Host Europe oder Strato seine statischen Daten zu Amazon S3 hochladen. Egal, wo es mir nicht mehr gefällt – mit einer Änderung in der Konfigurationsdatei und einem Knopfdruck kann ich mit all meinen Daten umziehen.

Mit diesem Entwurf habe ich einen langen Weg hinter mir. Ging ich bei meinen ersten Überlegungen (2003 in einer Keynote zur Blogtalk in Wien) noch davon aus, daß ein Community-Server und ein Trackback-Ping notwendig seien, um ein P2P Social Network zu schaffen, konnte ich zwar in späteren Überlegungen den Community-Server eliminieren, setzte dafür aber auf XMPP (Jabber) als verbindendes Protokoll. Erst langsam ging mir auf, daß die einfachste Lösung die sicherste Lösung ist und eine Lösung, die nur RSS resp. Atom als verbindendes Protokoll benötigt … einfacher geht es kaum.

Ich glaube nicht, hiermit den Stein der Weisen gefunden zu haben. Aber ich wollte die Idee einfach einmal niederschreiben, und sei es nur, um irgendje­man­den zuvorzukommen, der sich so etwas patentieren lassen und damit Geld verdienen will. Denn Trivialpatente sind ja gerade en voque in dieser seltsamen Zeit.

Teilen:
  • Facebook
  • del.icio.us
  • Google Bookmarks
  • MySpace
  • PDF
  • RSS
  • Technorati
  • email
  • Wikio
  • Digg
  • Identi.ca
  • MisterWong.DE
  • Posterous
  • Twitter
  • Print
  • Yigg
  • LinkedIn
  • FriendFeed
  • Tumblr

31 Kommentare

  1. Fast sagt:

    Der Evolutionssprung wird vielleicht mit ipv6 kommen. Jeder Rechner hat dann eine lebenslange Adresse und ist bestenfalls immer online. Fehlt nur der lokale Webserver und ein DnD Interface für Bilder und Videos. Schreiben sollte einfach da gehen, wo der Cursor blinkt. Es kann nicht so weiter gehen, dass alle privaten Daten immer auf Unternehmensservern gespeichert werden.

  2. xwolf sagt:

    ersetzt du jetzt nicht nur eine zentrale Instanz durch eine andere?

    dadurch, das du deine netzheimat als zentrale Quelle setzt und zu den anderen Netzen nur pusht anderst du nur den Ort, das Prinzip bleibt dasselbe.

    ich glaub du solltest die verteilte Publikation und datenhaltung mehr berücksichtigen. u.a. auch und gerade im Sinne der Redundanz.

    Beispiel Kommentare. wo gehört ein Kommentar eines deiner Artikel hin, den ich schreib?
    in deiner netzheimat oder in meiner? oder in beide? wer speichert den Text des Kommentares und hält ihn dann zuverlässig vor?

  3. name sagt:

    Warum lassen wir es nicht so wie es ist ?

    Es gibt so viel tolle Protokolle/Kanäle/Anwendungen mit denem man jetzt schon was anfangen kann. http als präsentation, ftp zum austausch irc/usenet/e-mail zur diskussion etc. etc.

    Ich finde es zb. schade dass der gopher support bald in den major browsern nicht mehr unterstützt wird. Weitere werden folgen…

  4. David sagt:

    Finde die Idee ziemlich interessant, hab mir auch schon überlegt, ob RSS nicht noch für was anderes als Bloglesen gut sein könnte, insbesondere da Facebook Activity-Streams oder Twitter Timelines ja (technisch) eigentlich nicht viel anders aussehen als Blogs.

    Allerdings gibt es möglicherweise ein Problem mit der Freischaltung von Freunden , da (anders als Blogger/Twitterer) nicht jeder sein Profil etc. allen öffnen möchte. Meiner Meinung nach bräuchte es an der Stelle noch eine Authentifizierung und Freischaltung, möglicherweise über htaccess, bzw. Atom sollte wohl eine Authentifizierung haben/bekommen (http://www.xml.com/lpt/a/1337) .

    xwolf: IMHO ist der Sinn dahinter, die zentrale Instanz von Dir gehört dir und du hast die Datenhoheit, meine dagegen würde Mir gehören. Sollte meine Instanz offline gehen (warum auch immer), könnten sich ältere Einträge zumindest kurz/mittelfristig (kann man ja konfigurieren) in den entsprechenden Eingängen/Readern meiner Freunde finden, so wie gelese RSS-Posts ja auch offline weiterhin verfügbar sind.

    Kommentare könnte man entsprechend aufteilen, auf der einen Instanz da Urheber, auf der anderen (zwischengespeichert) zum entsprechenden Beitrag. Problem wäre möglicherweise wie schnell Kommentare gelöscht werden können und komplett verschwinden…

  5. [...] Entwurf eines P2P Social Networks – Der Schockwellenreiter Entwurf eines P2P Social Networks. Dienstag, 11. Oktober 2011. von Jörg Kantel. Noch keine Kommentare. »The Internet is great because it is decentralized. If you centralize it, it stops being the Inte… [...]

  6. Uro sagt:

    Prinzipiel finde ich die prinzipielle Idee eines autarken P2P Social Networks recht charmant. Allerding ist deine Lösung meiner Meinung nach kein wirkliches P2P Social Network, da wichtige Bestandteile sozialer Interaktion, insbesondere die Interaktion in einer (auch größeren) Gruppe, fehlen.
    Ich versuche mich mal an einem Beispiel:

    Person A erstellt einen Beitrag. Person B kommentiert diesen oder teilt.
    Soweit so gut, nur wie gehts jetzt weiter?

    Was ist mit Person C, die auch kommentiert oder teilt und eine weitere Person im Umkreis von C kommentiert den geteilten Beitrag oder teilt weiter…das ließe sich ja nun beliebig fortsetzen und genau davon lebt ein soziales Netzwerk.

    Was davon landet nun im Stream von A (bzw. B oder C)?
    Wie kann A mit den von C geteilten und dort kommentierenden Personen interagieren?
    Wem gehören welche Daten, insbesondere die Kommentare und Teilvorgänge? Wo werden diese gespeichert?
    Wie kann B einen bestimmten Kommentar zurückziehen oder wie kann A den Zugriff und das teilen nur auf bestimmte Personen beschränken?
    Wie kann Person B die Sichtbarkeit z.B. von Kommentaren steuern?
    ….

    Abgesehen davon, dass noch ein Benachrichtungskanal etabliert sein muss (ich nehme an, das ist bei dir XMPP) muss der ganze Kram ja auch irgendwo eingesammelt und dann, vermutlich mehrfach redundant, gespeichert und natürlich auch jeweils verarbeitet und gerendert werden…

    Wie gesagt, ich finde die Idee eines dezentralen sozialen Netzwerks aus mehreren Gründen ebenfalls sehr interessant.
    Allerdings sollten wir dafür zunächst die prinzipiellen Anforderungen und Grundsätze eines solchen Systems überdenken und danach hergehen und schauen, mit welchen existierenden oder neuen technischen Komponenten das umsetzbar ist?

  7. xwolf sagt:

    Genau das was Uro verständlicher aufgeschrieben hab, meinte ich auch.

  8. xwolf sagt:

    (Verflixt, wieso hat der Returm das jetzt abgeschickt :=) ) Die Frage der Datenhoheit ist wirklich komplex. Bei einem Diskussionsthread allein müsste eigentlich jeder der beteiligten einen Teil der Datenhoheit in Anspruch nehmen. Dabei ergibt sich aber dann auch wieder die Frage der Verknüpfungen. Welches System verknüpft Meldungen wohin?
    Und wo findet die Diskussion überhaupt statt? Wenn diese z.b. hie rin diesem Blog startet, aber einer der Teilnehmer nun ebenfalls Datenhoheit durch seinen Beitrag erlangt, müsste der Thread dann nicht auch bei dem auftauchen. Un dkönnte dann nicht dort auch jemand kommentieren anstelle von hier?
    Bei Google Plus sehen wir die Problematik schon im Kleinen, wenn Beiträge geteilt werden. Wo werden diese Beiträge dann kommentiert?
    Beim originalen Poster oder bei dem der sie teilt? Beides ist möglich und beides wird gemacht.
    Die Lösung, daß einfach beim, der einen Originalbeitrag von jemand anders teilt. einfach kein kommentieren möglich ist, ist ebenfalls schlecht.

    Eigentlich geht es um Kommunikation.
    Wenn 2 oder mehr Leute kommunizieren, kann jeder sich später an das Gespräch erinnern, es aufschreiben oder eine Tonbandaufnahme verbreiten. Und dann können andere dazu Kommentare machen und weiter Kommunikation eröffnen.
    Wie und wo dies nun digital und eigentlich fast schon live gespeichert werden kann, ist die große Frage.

    RSS als Austauschformat ist sicher eine potentielle Basis.
    Ich glaub aber, ein Aufsatz auf REST wäre noch besser. Denn RSS ist zu linear und zu sehr festgelegt in seinem Datentypen. Wenn Kommunikation auf mehreren Servern gespeichert opder verknüpft werden sollte, reicht daher IMHO die RSS-Definition nicht aus.

    Rumgesponnen (ich hatte auch schon oft über das Thema gebrütet), würde ich sagen, daß bei jedem Teilnehmer des Netzwerkes eine entsprechende Client-Server-Lösung vorhanden sein sollte, die aber reaktiv ist. IaW: Teilnehmer B der Diskussion bei Teilnehmer A erhält beide Beiträge, sowie Verknüpfungen dazu. Diese werden dann auch auf seinen Server vorgehalten. Gleichzeitig müssen auf beiden Servern (automatisiert) “Agenten” instantiert, die den etwaigen Fortgang der Diskussion überwachen und an den jeweils anderen Server melden.
    Das entweder um weitere Beiträge oder zumindest weitere Verknüpfungen hinzuzufügen.

    Wenn nun ein Teilnehmer C hinzukommt, muss dies nun verdreifacht werden: C kopiert ja die Beiträge von A und B auf sein Server (denn er reagiert ja darauf auch). Damit wiederum müssen die Server von A und B auch darüber bescheid bekommen, damit sie nun auch den Server von C auf weitere neue Beiträge überwachen, die nun wiederum DORT erfolgen können.

    Hui, da wirds ganz schön Traffik geben :=)
    Aber denkbar wäre es.

  9. name sagt:

    Im Grunde sollten die Baukästen zur Präsentation der Daten die man selber veröffentlichen will, einfacher werden.

    Baukästen für die eigene Medienzentrale. Eine einfachere Möglichkeit Dinge online und somit öffentlich zu betreiben. Bisher ist alles getrennt und eher inkompatibel. Da die Webseiten Software, da der Blog und da das Forum und hier noch die Mails.
    Einfach ein Paket, dass jeder installieren kann und bedienen und somit auch wieder Herr ist über seine Daten.

    OT:
    Warum in aller Welt steht der Name, e-mail und URL schon vorausgefüllt in der Kommentar-Form und zwar DIE VOM KOMMENTAR VORHER ?
    Danke wolf für deine E-Mail….

  10. Uhu sagt:

    Sehr interessante Gedanken, natürlich auch in Verbdinung mit Dropbox oder vergleichbaren Systemen. Ich bin schön länger auf der Suche nach einem statischen Generator, der mir das alte Thingamablog (leider de facto tot) plattformübergreifend ersetzen kann.
    Die meisten Alternativen haben Schwächen, beispielsweise (wie bei TamB) nur einen Entwickler. Und Serendipity/WordPress kenne ich halt nur als reine Online-Dienste ohne die lokale Datenbank, und eben die möchte ich dabei nutzen.

    Ich bin gespannt auf das Ergebnis, hoffe nur, daß es auch endnutzerfreundlich gestaltet werden kann (keine aufwändige Einarbeitungs- und Installationsbegreif-Zeit). Denn TamB wird sicherlich bei einem künftigen Java-Update die Läden schließen …

  11. Uro sagt:

    Wie ich bereits sagte, sollten wir erstmal die Anforderungen aufnehmen. Zum beispiel sollte das System offenene Schnittstellen haben und die technische Einstiegshürde sollte sehr niedrig sein. Konkrete technische Lösungen fallen mir auch einige ein…
    Im “echten Leben” würde ich jetzt vorschlagen, einen entsprechende Workshops zur Anforderungsaufnahme und Analyse anzusetzen. :-)
    Kennt ihr denn ein Werkzeug oder Plattform wo wir die Idee gemeinsam bis zum Konzept oder zur lauffähigen Version weiterspinnen könnten?

  12. why.n0t sagt:

    Nur zum Verständnis.

    Schlägt Diaspora nicht in eine ähnliche Kerbe?
    Wobei man hier aussuchen kann, ob man tatsächlich einen eigenen Seed betreibt und sich mit den restlichen verbindet, oder einem größeren Anschliest der sich wiederum vernetzt.

  13. Jörg Kantel sagt:

    Okay, ich handle die Kommentare jetzt auch mal en bloc ab:

    1. Ob IPv6 wirklich eine Verbesserung bringt, da bin ich mir nicht sicher. Der Gedanke, daß jedes meiner (mobilen) Geräte eine eindeutig identifizierbare IP-Adresse besitzt, läßt mich eher schaudern. Die Idee meiner Lösung ist ja gerade, daß der »Redaktionsserver« von außen nicht sichtbar ist (und auch nicht sein muß/soll). Das macht die Angelegenheit sicher — gerade wenn man davon ausgeht, daß solch eine Software von Menschen betrieben wird, die vielleicht nicht gerade ein Informatikstudium hinter sich haben. Das ist auch einer der Hauptunterschiede zu Diaspora, denn dort sehe ich notorische Sicherheitsprobleme.

    2. Redundanz ist gewollt. Hier haben verteilte Systeme wir Git oder Mercurial Pate gestanden.

    3. Prinzipiell ist das System so angelegt, daß die »Datenhoheit« immer beim Autoren liegt. Wenn ich kommentiere, kommentiere ich auf »meinem« Redaktionsserver. Der Kommentierte kann (muß aber nicht) sich den Kommentar via RSS/Atom abholen und auch bei sich speichern. Das entspricht auch einer alten Idee Winers (der Weblogkommentare gar nicht mag), daß jeder Kommentare nicht im Blog des Kommentierten, sondern in seinem Blog absetzen soll. Dadurch wird auch das Spam- und Troll-Problem massiv entschärft.

    4. Seit meinem Mathematikstudium weiß ich, daß man den »Mut zur Lücke« haben muß. In der von mir vorgeschlagenen Lösung erfahre ich sicher nicht alles, was über mich geschrieben und/oder über meine Beiträge kommentiert wird. Aber auch heute ist das schon so (ich habe einen Google Alert für den Schockwellenreiter laufen und bin regelmäßig schier erstaunt, was ich darüber zusätzlich erfahre — vieles davon will ich eigentlich gar nicht wissen).

    5. Das System ist von der Idee her symmetrisch angelegt und geht — ähnlich Facebook oder Twitter — davon aus, daß jeder, der mir folgt (der meinen RSS-Feed abonniert hat) auch von mir gefolgt wird (daß ich auch seinen RSS-Feed abonniere). Die asymmetrischen Kreise von Google+ irritieren mich. Das ist aber nicht zwingend — nur werden dann unter Umständen eben die oben angesprochenen »Lücken« größer.

    6. Es gibt nur eine Schnittstelle und die ist selbstverständlcih offen. Denn es ist der RSS-/Atom-Feed. Nur über den kommunizieren die einzelnen Clients miteinander. Mehr ist nicht vorgesehen, da ich der Meinung bin, daß alles weitere die Einfachheit des Systems stören würde.

    7. Aus dem gleichen Grund habe ich keine Authentifizierung vorgesehen. Ich bin vielleicht zu sehr dem wissenschaftlichen und journalistischen Bereich verbunden. Mein System ist ein System für Menschen die »aller Welt« etwas mitzuteilen haben. Wer das nicht will, kann es aber immer noch nutzen, um die Sozialen Netzwerke seiner Wahl (Facebook, Twitter, Google+) mit deren Einschränkungen auf bestimmte Leserkreise zu füttern. Der Vorteil wäre immerhin noch der, daß die Daten (Beiträge, Photos), auf seinem Rechner verbleiben und er so die Datenhoheit behält.

    Das wäre es erst einmal. Einige Einwände/Fragen habe ich (noch) nicht ganz verstanden und werde daher erst noch einmal darüber nachddenken. Ihr werdet mit Sicherheit zu diesem Thema von mir noch mehr hören.

    Danke an alle erst einmal für die Kommentare. Denn Ihr habt Euch richtig Mühe gegeben und Ihr helft mir auch dabei, meine Ideen zu konkretisieren und meine Gedanken zu schärfen. Das wäre ohne das Netz (so schnell) nicht möglich und darum liebe ich es. (Und das hier ist kein abschließender Kommentar, ich bin um jeden weiteren (auch kritischen) Beitrag froh.)

  14. cornholio sagt:

    gibts doch schin zum selber machen und noch vieles mehr:
    http://retroshare.sourceforge.net/index_de.html

  15. Fast sagt:

    > Der Gedanke, daß jedes meiner (mobilen) Geräte eine eindeutig identifizierbare IP-Adresse besitzt, läßt mich eher schaudern.

    Wie könnte denn technisch der Übergang von öffentlich und lokalisierbar zu anonym und nicht lokalisierbar aussehen?

  16. Dahie sagt:

    An dieser Stelle würde ich gerne auf das Projekt distripedia verweisen:
    http://www.distrifriends.com/

    Es ging darum eine Html5-Javascript Webapplication zu schreiben, die eine eigene Instance hat und sich mit den Instanzen anderer User mittels Websockets verbinden kann. Das Projekt lief 1 Semester bis Juli und ich weiß gerade nicht ob daran noch weiter entwickelt wird. Glaub eher nicht. Den Sourcecode gibt es hier:

    http://code.google.com/p/distrifriends/

  17. Guybrush sagt:

    Interessante Idee, aber Facebook & Co. werden doch nicht hauptsächlich kritisiert, weil man Datenverlust befürchtet (theoretisch, könnte man sich ja täglich ein Backup ziehen, Facebook bietet das doch neuerdings). Der Hauptkritikpunkt ist doch eher, dass Facebook die eigenen Daten hat und damit Schindluder treiben kann. Das sehe ich hier nur gelöst, wenn man das ganze eben nicht noch zu den bestehenden Netzwerken pusht und, wie David schreibt, eine Authentifizierung einbaut.

  18. Jurassic sagt:

    Der vorgestellte Ansatz ist durchaus interessant, aber das Problem der “Datensilos” löst er leider auch nicht. Zwar behalten die Autoren lokal die Kontrolle über ihre Daten, sobald sie aber einmal die eigene Einflussspähre verlassen haben ist es mit der Kontrolle schnell vorbei.
    Das Konzept sieht jetzt schon eine quasi einseitige Ankopplung an Facebook, Twitter & Co. vor. Und damit landet zumindest ein Teil der Daten genau in den Silos aus denen sie das Konzept eigentlich heraushalten wollte.

    Nun kann man sagen “Gut, das sind eh Dinge, die Autoren bewusst publizieren und öffentlich zugänglich machen, Dinge also, die auch Facebook & Co. im Zweifel wissen düfen”. Was aber, wenn ein Autor seine Meinung zu einem Thema im Laufe der Zeit überdenkt? Bei echter Datenhoheit liesse sich dann ein Beitrag gänzlich löschen, beim vorgestellten Konzept funktioniert das aber leider auch nicht.
    Ein kleines Beispiel, um zu verdeutlichen, wieso soetwas ggf. sinnvoll sein kann: Ein Autor verbringt in B-Stadt, A-Land am Flüsschen C seinen Urlaub. Es regnet zwei Wochen in Strömen, schon der Taxifahrer am Flughafen war unfreundlich, die Ferienwohnung hätte vor Ankunft dann doch mal gereinigt werden dürfen und die örtlichen Restaurants lassen den Wunsch nach einer nahegelegenen Filiale eines Fast-Food-Konzerns aufkommen. Entsprechend fällt der Blog-Eintrag zum Urlaub aus. Eine Weile später muss unser Autor vielleicht dienstlich wieder nach B-Stadt, diesmal scheint die Sonne, die Leute scheinen freundlicher, das Hotelzimmer ist einfach aber sauber, und die Landschaft drumherum scheint traumhaft, wenn sie nicht gerade von Regenwolken erdrückt wird — am Ende der Dienstreise beschliesst der Autor, im nächsten Urlaub einfach nochmal nach B-Stadt zu reisen, am Ende ist der Blig-Beitrag mit “Traumurlaub” überschrieben. Bei echter Datenhoheit gibt es dann den alten Beitrag nicht mehr, er wird ggf. im neuen Beitrag in relativierter Form verarbeitet, erscheint dem Autor aber als alleinstehender Beitrag nicht mehr angemessen. Derzeit jedoch hat der Autor weder mit dem hier vorgestellten Konzept noch sonst eine halbwegs realistische Chance seinen Beitrag quasi “aus dem Internet zu löschen”.
    Dafür bräuchte es zumindest soetwas wie ein von allen Beteiligten akzeptiertes und umgesetztes Protokoll, dass derartige Beiträge mit einer maximalen Lebensdauer versieht, nach der sie an allen speichernden Stellen ganz schlicht und einfach gelöscht werden, so dass sie nur noch an der sie ursprünglich versendenden Stelle vorhanden sind. Ein solches System liesse sich ggf. noch deutlich erweitern, indem die speichernden Stellen vor dem Löschen prüfen, ob die Lebensdauer des Beitrags ggf. verlängert wurde. Oder beispielsweise auch dadurch, dass die Lebensdauer für verschiedene Formen der Speicherung differenziert definiert werden kann.
    Ein solches System vorausgesetzt gäbe es eine Chance auf echte Datenhoheit.

  19. Jörg Kantel sagt:

    @Jurassic: Das nachträgliche Löschen von Beiträgen, also daß sich jeder seine Geschichte »schön« schreibt, ist natürlich jedem Historiker ein Graus. Bei einem Buch oder einer Zeitschrift ist das ja auch nicht möglich, man kann nur in einer späteren Ausgabe seine Fehler, Einschätzungen oder Urteile korrigieren. Und ich möchte eigentlich, daß genau so auch mit Publikationen im Netz verfahren wird. Denn auch Publikationen im Netz sind »Quellen«, die es zu bewahren gilt (auch wenn da noch eine große Aufgabe vor uns liegt — das mit dem »Bewahren« klappt meistens noch nicht wirklich).

  20. [...] Entwurf eines P2P Social Networks – Der Schockwellenreiter – Denker unter sich: Dave W. und Jörg K. [...]

  21. Alp sagt:

    Ich habe eben diese Idee erst letzten Monat mit einem Kommilitonen dikutiert und wir sind dabei auf einige Probleme gestoßen:

    Wie sieht das dann aus, wenn ich mal nicht Zugriff auf meinen Rechner habe? Muss ich dann die Daten nicht trotzdem auf einem USB-Stick mit mir führen? Und wie sieht es dann mit der Aktualität der Daten auf dem USB-Stick aus?

    Ich weiß auch nicht ob das in großem Maßstab funktionieren würde. Es ist auch sicher nicht jeder User dazu bereit Speicherplatz auf seinem Rechner für sowas zu opfern und nach ein paar Jahren wird die Datenmenge auf dem eigenen Rechner sicher auch sehr groß, sodass man sowieso wieder auslagern oder eben löschen müsste.

  22. Jurassic sagt:

    Den Punkt — ein kurze “Lebensdauer” der eigenen Ergüsse im Netz kann der Qualität der Beiträge abträglich sein oder gar zu einer Art Geschichtsfälschung führen — sehe ich durchaus.

    Andererseits unterscheidet sich eine Veröffentlichung im Netz deutlich von der in anderen Medien. Bei Veröffentlichung in einer wissenschaftlichen Zeitschrift kann ich mir beispielsweise halbwegs sicher sein, dass ein ggf. nötiges erratum die Leserschaft des ursprünglichen Beitrags weitestgehend erreicht. Bei einem Blog-Eintrag ist das im Zweifel deutlich anders, ein guter Teil der Leserschaft ist nicht unbedingt “Stammpublikum”, mögliche Korrekturbeiträge erreichen die Leserschaft des ursprünglichen Beitrags mit weitaus geringer Wahrscheinlichkeit. Gleichzeitig liefern Google & Co. den fehlerhaften Beitrag ggf. weiter als Resultat einer Suchanfrage, und das möglicherweise in einer Form, in der neue Leser kaum eine Chance haben das erratum zu diesem Beitrag zu finden.

    Nehmen wir ein weiteres Beispiel: Ein Jurist schreibt in seinem Blog seine Einschätzung zu aktuellen rechtlichen Fragestellungen nieder. Nach ein paar Jahren muss er erkennen, dass einer seiner Beiträge vor dem Hintergrund neuer höchstrichterlicher Entscheidungen nicht mehr die aktuelle Rechtsprechung widerspiegelt, obwohl er zum Zeitpunkt des Verfassens die herrschende Meinung vertreten hat. Google liefert seinen schlicht veralteten Ursprungsbeitrag bei entsprechender Suchanfrage als zweiten Link, sein erratum taucht dann irgendwo jenseits vom 100. Link auf.
    Hätte er in einer jursitischen Fachzeitschrift publiziert, so wäre dort der veraltete Beitrag selbstverständlich noch gelistet, gelesen würde aber sein aktueller Beitrag, der ggf. die Verändungen der entsprechenden Rechtsprechung beleuchtet.

    Der Charakter einer Blog-Veröffentlichung und die Form in der Online-Beiträge rezipiert werden unterscheidet sich in meinen Augen merklich vom Umgang mit “Offline-Medien”. Die richtige Kultur im und die entsprechende Technik für den Umgang mit diesen Unterschieden müssen wir als Gesellschaft vermutlich erst noch entwickeln, um einerseits sicherzustellen, dass längst korrigierte und/oder vollständig zurückgezogene Beiträge nicht auf ewig weiterleben und als vermeintlich aktuelle Quelle herangezogen werden und dass andererseits Mechanismen, die das Löschen von Beiträgen ermöglichen nicht vornehmelich der Verfälschung der Vergangenheit dienen.
    Aber ich fürchte das ist ein weites Feld, vermutlich ein zu weites für eine Diskussion in einem Blog… ;-)

  23. Keine Namen sagt:

    Broadcast oder Unicast oder kleine ‘Groups’. Davon hängt der Traffic ab.
    Weiterhin wer bearbeitet und ob der Workflow Kommentare wie z.b. Tippfehler und Formulierungs-Schwächen-Hinweise von Freunden oder Kollegen erlaubt.
    Zuerst dachte ich, Du hostest bei dropbox. Aber das ist nur ein Hub für Deine Rechner. Das Hosting läuft per normaler RSS/Bloghoster als Fulltext oder Link auf Public Webserver.
    Danach hast Du je nach Hoster aber nicht immer volle Kontrolle über die Daten.

    Was google nicht versteht, obwohl es Facebooks “alles sind Freunde” durch Gruppen eine Evolution höher schob: Rollen. Lagerfeld will private Messages loswerden, er will als Fotograf posten und als Büchersammler und als Modemacher. Jeder hat Rollen und die Tools sollten Settings dafür anbieten, die man wählen kann. D.h. für Dein Agility hättest Du andere Settings als für dieses Projekt und wieder andere für andere Dinge wie die Organisation der Firmen-Weihnachtsfeier für Mitarbeiter und gute Kunden.
    Googles+ Gruppen sind nur Rollen für andere. Die google+-Realname-Diskussion und neulich die Grünen die einem das Twitter-Posting verbieten wollten (oder so ähnlich) weil für die Leser unklar war, ob er im Namen der Grünen Stadtfraktion oder als Grüner Abgeordneter oder als Privatperson twitterte, zeigt aber auf, das Rollen für einen selber (bis hin zu echt anonym) auch relevant und nötig sind.

    Es wäre schön, sowas “bevor es wer patentiert” wiki-mäßig sammeln zu können.
    FSF, Piraten usw, scheinen leider nicht im geringsten an technologischen konstruktiven Diskussionen interessiert zu sein. Leider gibts keine freien Server wo man sowas sinnvoll diskutieren kann. Und ein Staatsprogrammierer wird sich nicht als Erfinder von Wahl-be-oba-cht-ung oder DrPlagiatorFinder o.ä. outen wollen weil er dann für immer in Armut leben “darf” weil viele NGOs oft keine relevanten Gehälter (ausser für Berater und Geschäftsführer und nicht für die 99% unbezahlten Praktikanten) bezahlen.

    Ergänzung: Verschiedene Text-Sorten bieten sich mit ID und vermutlich auch Versionsnummern an.
    D.h. wenn der Blog gelöscht wird, hat man die URI (nicht URL!) docid:schockwellenreiter/id=0815&ver=v1.2&date=2011-Okt-12 in seinen Kopien drinstehen und kann google sei dank weltweit danach suchen und die docID: oder “schockwellenreite:0815″ weiter verlinken. Vermutlich gibts schon technische Definitionen dafür.
    Dann bieten sich noch Keys an mit denen die Message signiert wird wenn man will, damit böse Feinde keine abgefälschten Versionen veröffentlichen.
    *:* ist in der IT immer besser als 1:1 . Die Anfängers die gegen KV-Datenbanken waren und nur 1:1 oder 1:n beherrschen, sind halt die überbezahlten Verhinderer.
    Man kann den Spiegel überall kaufen und hat ihn dann, auch wenn er verboten wird. Technische Sonderhefte gibts nur in größeren Zeitschriften-Shops. Man kann “schockwellenreiter:0815″ dann (per Google) an mehreren Stellen finden. Selbst wenn man nur an einer Default-Stelle postet, muss man immer damit rechnen, das die “garantiert Lebenslange” EMail-Adresse oder BlogHoster doch gelöscht wird und man woanders das Posting hochladen muss. Also plant man es schlauerweise im Voraus. IDs wären vielleicht eine relevante Idee. Notfalls der Titel aber “weihnachtsgrüße von Schockwellenreiter” gibts jedes Jahr neu und kann man schlecht tweeten oder auch im Literaturverzeichnis sind IDs eindeutiger.

  24. Uro sagt:

    GIT wäre vielleicht ein Ansatz, das Problem der Versionen und der verteilten Kopien zu lösen. Allerdings ist das auch wieder nur eine technische Lösung für ein Teilproblem, was hier in der Diskussion noch nicht ganz vollständig beschrieben ist.

    Mir ist immer noch nicht ganz klar, ob wir hier von einem Social Network sprechen oder nicht doch eher sowas wie ein statisches Blog meinen?
    Sprechen wir vom Social-Network oder vom (wissenschaftlichen) Publizieren?
    Schlussendlich die Frage “Was ist Social-Network?”

    Für mich geht es dabei vor allem um mich im Internet. Um die Vernetzung, um neue Formen des Publizierens, den Austausch mit Freunden und dem teilen mit der Welt.
    Ich denke sehr wohl, dass es essentiel wichtig ist, dass ich in dieser Welt selbst bestimme, was für die Nachwelt von mir erhalten bleiben soll.
    Das die Daten mir gehören, gerade weil eine Kopie zu einfach ist; dass ich deshalb auch die Kontrolle über meine Daten nicht abgeben will und bestimmen will, wer was wie lange sehen und damit machen kann.

    Für das reine Publizieren in verschiedene Quellen gibt es ja nun mehr als genug Werkzeuge.
    Das ist aber nicht Social-Network, sondern veröffentlichen in verschiedenen Kanälen. Im klassischen Medienvergleich: der Verkauf meiner Zeitung im Bahnhofskiosk, in der Abozustellung und im gut sortierten Buchhandel. Technisch lösbar mittels RSS und jeder mittelmäßgen Blogsoftware.
    Nur eine entscheidende Zutat fehlt dabei: Die Interaktion – die Möglichkeit, mit anderen in Kontakt zu treten, zu teilen, zu kommentieren und vielleicht auch zu ändern. Und nicht zu vergessen: es fehlt die Kontrolle, um selbst zu bestimmen, wer was von mir sehen und nutzen darf.

  25. Jurassic sagt:

    Die spannende Frage ist, ob manche Formen klassischen Publizierens nicht aus diversen Gründen mehr und mehr aussterben und von Publikationsformen die sozialen Netzwerken jedenfalls nicht unähnlich sind verdrängt werden?

    Wissenschaftliche Publikationen führt man sich schon heute fast ausschlielßich online zu, ein gebundenes Journal hatte ich schon seit Jahr und Tag nicht mehr in den Händen.
    Da liegt es fast nahe, dass beispielsweise die Art, wie Wissenschaftler ihre Ergebnisse in Zukunft publizieren sich grundlegend ändert. Und auch die Art, in der die wissenschaftliche Gemeinschaft Ergebnisse bewertet und diskutiert wird sich ändern. Solche Prozesse laufen mehr und mehr vernetzt ab, und eine in meinen Augen durchaus interessante, weil sehr offene und deshalb täuschungssichere Form könnte dem, was sich in den letzten Jahren als “social networks” entwickelt hat durchaus verwandt sein. Ob ich nun Informationen, Gedanken und Daten mit Facebook-”Freunden” oder mit Kolleginnen und Kollegen austausche ist technisch betrachtet herzlich egal. Ob ein “normaler” Blog-Beitrag kritisch hinterfragt wird oder eine wissenschaftliche Arbeit ist technisch betrachtet herzlich egal, und wie effektiv die vernetzte Auseinandersetzung mit wissenschaftlichen Werken sein kann haben ja vor nicht allzu langer Zeit etliche detusche Politikerinnen und Politiker zu spüren bekommen.

    Das Potenzial von “social networking” liegt weit über dem — mit Verlaub — “Belanglos-Tratsch” der dort heute häufig zu finden ist. Die gleiche technische Basis, mit der dort Leute aller Welt ihren Stuhlgang näherzubringen versuchen taugt eben auch für weltweiten wissenschaftlichen Diskurs oder, jedenfalls in gewissen Grenzen, globale politische Meinungsbildungsprozesse, beides in Echtzeit und im Zweifel in Farbe mit Bild und Ton.

    Damit soetwas aber funktionieren kann braucht es Ansätze wie den hier vorgestellten, da derartige Prozesse auf den Platformen kommerzieller oder anderweitig interessengesteuerter Dienstanbieter nur schwer vorstellbar sind.

  26. Sebastian sagt:

    Vielen Dank für das interessante Brainstorming.
    RSS ist eine tolle Technik und ich persönlich wäre sofort von einer solchen Software begeistert – sie müsste jedoch so einfach und verständlich und schnuckelig sein wie E-Mail, damit jemand wie mein Daddy damit klarkommt. Mit der Redundanz habe ich keine Probleme – es ist ohnehin eine Illusion, dass man Inhalte aus dem Netz nehmen kann, sobald man sie dort verbreitet. Eine E-Mail kann ich auch nicht zurückholen. Gesagt ist gesagt.
    Doch, ich glaube, das ist der richtige Weg, ein Standard-Format für diesen Zweck zu gestalten. Einzige Tücke, die ich auch sehe ist die der Authentifizierung – damit ich festlegen kann, wer die Information abrufen kann / zu wem sie gepusht wird. Mit Schlüsseln? Die kann man in unbegrenzter Zahl verteilen und auch wieder selbst ungültig erklären. Sie haben nur den Zweck, dass die Inhalte nicht öffentlich sind.
    Ich kann auch bei FB oder G+ oder E-Mail nicht verhindern, dass jemand einen privaten Inhalt per copy+paste an Leute weiterverbreitet, denen ich eigentlich keinen Schlüssel dafür gegeben habe. Das hat was mit Vertrauen zu tun. Die Frage ist – vetraue ich meinem Netzwerk oder einem Unternehmen?

  27. [...] könnt. Falls Ihr ein Ruby on Rails darauf installiert habt. Ein weiterer Baustein für ein selbstverwaltetes Peer-to-Peer-Netz. [Peter van I. per [...]

  28. Robert sagt:

    Ich hatten eine ähnliche Fragestellung 2008 in ein Konzept gepackt und umgesetzen lassen. Die Richtung ist “Schwarze Bretter” in Räumen, deren Schlüssel der Author als initiale Einladung verteilen kann. Die Bedienung ist sehr einfach gehalten, um den Austausch von Themen mit Kommentaren, Listen, Dateien auch mit “ungeschulten” Anwendern zu ermöglichen. Jedes Thema und zugehörige Teile (Kommentarfunktionen, Listen etc.) davon können je Person mit Häkchen (lesen / kommentieren bzw. lesen / abhaken etc.) freigeschaltet werden.
    Es gibt eine Schnittstelle, um die Inhalte in viele Formaten (html, txt, csv, tsv, json etc.) zu importieren / exportieren. Die Erweiterung für den Mailversand an eine “Themengruppe” wurde bereits entwickelt und wäre schnell zu integrieren.

    Seit uns ein Cloud-Ausfall für einige Stunden ausbremste reift ein P2P-Konzept. Dank DSL/VDSL könnte ein Mini-Server als “Basis” neben dem Router stehen und per dyndns erreichbar sein. Betreibt irgendwann eine weitere Person einen eigenen Server, trägt der “neue” Betreiber seine “Home-URL” in sein Profil auf dem ersten Server ein. Damit werden alle ihm zugänglichen Themen bzw. Teile automatisch auf seinen Server synchronisiert. Werden z.B. Artikel verfasst, würden Zielsystem(e) definiert.
    Für Unterwegs kann ein LAMPP / XAMPP / MAMPP auf einem USB-Stick als Server fungieren und sich bei Verfügbarkeit der eigenen Basis synchronisieren.

    Im DB-Umfeld gibt es bereits einen potentiellen Kandidaten, der Master/Master-Synchronisation, Versionierung etc. bereits beherrschen.

    Redundanz ist aus meiner Sicht im “echten Leben” gewünscht. Eigene Artikel können lokal verfasst werden. Sie könnten dann auf Wunsch mit einem oder mehreren Blogs/Systemen synchronisiert werden. Fallen die Server aus, ist der Artikel nicht weg. Stellt man z.B. eine Zusammenfassung und Fotos der letzten Feier zusammen, sollen andere Personen den Artikel und “Abzüge” der Bilder auch direkt auf ihren “Peer” bekommen. Korrigiert jemand etwas, erhält jeder Peer den aktuellen Stand. Die bisherige Version verbleibt erstmal bis auf weiteres als Vorversion enthalten.

    Für die Umsetzung des Konzepts der P2P-Version muss ich aber noch etwas sparen.

  29. Robert sagt:

    Natürlich kann das jetztige System besichtigt werden und ein Austausch ist auch möglich, falls interesse besteht.

  30. [...] Entwicklung ist besorgniserregend und nach wie vor bin ich der Meinung, daß nur ein freies P2P-Netz, bei dem die Beiträge denen gehören, die sie verfaßt haben, da gegensteuern kann. Denn heute ist [...]

  31. [...] Darum interessieren mich ja auch die Anstrengungen Winers, den »Datensilos« zu entkommen. [Spiegel Online] Teilen:Wo Sascha Lobo Recht hat, hat er Recht! Euer Internet ist nur geborgt: Dabei kann man auf einem Blog machen, was man möchte. Ärgerlicherweise bedeutet das auch, daß man machen… [...]

Einen Kommentar verfassen

Mit dem Absenden Ihres Kommentars willigen Sie ein, daß der angegebene Name, Ihre Email-Adresse und die IP-Adresse, die Ihrem Internetanschluß aktuell zugewiesen ist, von mir im Zusammenhang mit Ihrem Kommentar gespeichert werden. Die Email-Adresse und die IP-Adresse werden natürlich nicht veröffentlicht oder sonst weitergegeben.