Request for hosting - was: Fwd: Ist die Botschaft von Richard Stallman zu extrem?

Paul Hänsch paul at fsfe.org
Di Mär 1 16:02:54 UTC 2016


Na jetzt hast du aber ein rotes Tuch ausgepackt...

On 2016-02-29 22:44, Florian Ermisch wrote:
> Oh, jetzt ist pump.io tot, aber status.net lebt als GNU social
> weiter? Hatte ich nicht wirklich mitbekommen ^^"

Sowas schläft eben ein wenn der Entwickler den Bachelor fertig hat.  
Anstatt ein Protokoll zu beschreiben, oder zu spezifizieren welche  
Informationen überhaupt übertragbar sein sollen, haben uns diese  
Projekte mit einer API-Definition gesegnet. Die Entwicklerdoku fängt  
dann an mit: "lad unsere Ruby/NodeJS/Go Bibliothek runter und führe  
unseren Code aus und wir machen dann alles für dich". Als Entwickler  
ekel ich mich vor sowas. Um eine Technologie zu verbreiten Skaliert das  
auch nicht so richtig.

Am anderen Ende des Spektrums stehen RSS und Atom, diese sind  
ausgezeichnet dokumentiert, vielfach implementiert, und erweiterbar.  
Authentifizierung und Integritätsnachweise können jeweils auf Ebene des  
Transportprotokolls (HTTP/HTTPS) eingerichtet werden. Wordpress nutzt  
den Ansatz seit (>10) Jahren um Querverlinkungen und Leseempfehlungen  
zu verbreiten.

> Vermutlich wäre es bei sowas sinnvoll, den Mechanismus der
> Kommunikation Server-zu-Server nicht direkt zu spezifizieren,
> also nicht auf ein Protokoll/eine API festzulegen.

An einem einheitlichen Protokoll ist nichts verkehrt. Nur ein kleiner  
Tip für das Bullshitradar: Wenn die Protokollspec mit Downloadlink und  
Installationsanleitung beginnt, dann ist es keine.

> Dann bedeutet der Wegfall einer Plattform nicht ein Ende der  
> Kommunikation.

Kleine historische Leseprobe:
https://en.wikipedia.org/wiki/Openid
https://en.wikipedia.org/wiki/Oauth

OAuth ist eine weitestgehend sinnvolle Erweiterung von OpenID, beides  
sind offene Standards. Allein hat man bei OAuth unglücklicherweise die  
Funktion zur Ermittlung des Service-Endpunkts vergessen. Der Benutzer  
kann damit damit bei OAuth keinen ID-Anbieter mehr frei eingeben.  
Stattdessen stellt der Diensteeanbieter eine Auswahl zwischen den  
ID-Anbietern, die er schon kennt. Jedesmal wenn euch eine Webseite  
anbietet euch entweder via Google+ oder Facebook oder Twitter  
ainzuloggen, habt ihr es mit OAuth zu tun. Ratet mal wer beim  
Protokollentwurf im Komitee saß.

Wie auch OpenID ist das Protokoll zwischen Plattformen übertragbar,  
anders als dort sind die verwendbaren Plattfomen aber mehr oder minder  
zentral festgelegt. Fällt eine weg [*], endet die Kommunikation für ein  
Groß der Teilnehmer auf einmal.
Mein Punkt bei der Sache: weder Freie Software noch ein offener  
Standard sind alleinige Garanten für eine Netzwerkstruktur, die zur  
Teilnahme einlädt.

* Der Wegfall einer Plattform besteht effektiv auch dann, wenn einem  
das Benutzerkonto gesperrt wird, oder die AGBs untragbar werden (und  
idR. sind sie das ja schon).

> Ist aber natürlich aufwändiger zu implementieren.

Wenn ein Programmierer ein Netzwerksystem entwirft, dann erwarte ich  
dass der Entwurf mit der Beschreibung des Transferformats beginnt.  
Drauf los zu programmieren und hinterher die Funktionsschnittstellen zu  
erklären, die dabei entstanden sind ist ganz *hust... unerfahren.

> Muss denn jeder Knoten jedes Video vorhalten?
> Da fallen mir schon zwei andere Varianten ein:
> - - Auf dem kleinen, privaten Server können privilegierte
>   User zu spiegelnde Videos festlegen
> - - Größere öffentliche Instanzen können nen Schwellenwert
>   setzen, ab wievielen "Likes" ein Video gespiegelt wird und
>   bei zuendegehendem Speicherplatz eventuell unbeliebtere
>   "rausaltern" lassen

Braucht übrigens nicht im Protokoll festgelegt werden, weil es ohnehin  
alleinig in der Entscheidunsmöglichkeit jedes Knotens liegt.

> Zusätzlich kann die Quelle in den Metadaten festgehalten
> werden, so daß der dritte Knoten schon den ersten und
> zweiten kennt und anderen als weitere (mögliche) Quellen
> angeben kann, wenn er selber Quelle ist.

Schon wieder denke ich an RSS.

> Wenn man beim Transportmechanismus zwischen Servern
> auch Plugins/Module erlaubt, ließen sich zusätzliche Protokolle
> wie Rsync oder BitTorrent nutzen - und Usern könnte man zum
> Download gleich einen Metalink anbieten.

Schon wieder denke ich an RSS.

> > Wenn man nur die Links verteilt und die Videos auf den
> > jeweiligen Instanzen bleiben, hat man immerhin den Vorteil
> > einer durchsuchbaren Lösung, dann halt ohne Redundanz.
> 
> Ich weiß nicht, wie man bei sowas eine "globale" Durchsuchbar-
> keit ermöglichen würde, aber eine optionale Redundanz der
> Videos würde vermutlich ausreichen.

Wie finden wir denn Texte und Bilder? Das geht doch über Suchmaschinen  
ganz gut. Diese sind zwar ihrerseits eher zentralistisch, das hat aber  
immernoch eine ganz andere Qualität als die Inhalte bei Vimeo zu  
zentralisieren.

> [...]
> Und Videos sollten UUIDs oder ähnlich große Prüfsummen
> als Identifikationsmerkmal benutzen, die für eine Indizierung
> genutzt werden können.

Schon wieder denke ich an RSS.
(und BitTorrent)

> > Mögliche Kandidaten für eine solche Lösung wären GNU
> > social oder Hubzilla (es gibt bestimmt noch mehr, die ich
> > nicht kenne).

Klick mal den Downloadbutton da weg und lies was durchdachtes:
https://tools.ietf.org/html/rfc4287

-- 
Paul
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20160301/f0c1a7d8/attachment.sig>


Mehr Informationen über die Mailingliste FSFE-de