… WeiterlesenSocial Swarm soll kein weiteres soziales Netzwerk werden. Es ist ein loser Zusammenschluss von Entwicklern, Programmierern und Aktivisten, die das Problem diskutieren, eine Lösung herausarbeiten und in der Bevölkerung etablieren wollen. Eine zurzeit diskutierte Idee: Internetnutzer sollen sich über verschiedene soziale Netzwerke einloggen und dann untereinander vertraulich kommunizieren können. Möglich wäre das dann, wenn die Betreiber von sozialen Netzwerken offene Schnittstellen anbieten. “Wenn man sich beispielsweise bei Identica einloggt”, so Tangens, “soll man über offene Schnittstellen mit denjenigen kommunizieren können, die sich bei Diaspora angemeldet haben.” Sowohl die Microblogging-Software Identica als auch die Netzwerk-Software Diaspora sind Open-Source-Projekte, die bewusst auf offene Kommunikationsschnittstellen setzen.
Open Web
Sind Like-Button-Gegner gegen ein dezentrales Web?
Ist denen, die gegen eine möglichst einfache und damit datenweiterreichende Einbindung des Like-Buttons argumentieren, eigentlich klar, dass sie gegen Dezentralisierungstendenzen im Web argumentieren?
Jede Einbindung von Funktionen eines Dritten in eine Website wird Daten an diesen Dritten weiterleiten. Die Zwei-Klick-Lösung von heise (Erst nach dem Ja-ich-will-sharen-Klick erscheint der eigentliche Like-Button.) ist bestenfalls eine Lösung nur für den Like-Button. Dieser Button ist eine sehr simple Funktion, die 2010 eingeführt wurde.
Was ist mit eingebetteten YouTube-Videos? Was ist mit externen Kommentarsystemen von Livefyre oder, wie hier, Disqus? Soll alles erst nach einem „Ja, zeig mir das bitte.“-Klick eingeblendet werden?
Was ist mit den von Netzaktivisten verzweifelt herbeigewünschten dezentralen Alternativen zu Facebook und co.?… Weiterlesen
Das Versagen der offenen Webstandards
Auf Google+ habe ich einen Artikel von Nick Bradbury, unter anderem Entwickler von FeedDemon/NetNewsWire, verlinkt, in dem dieser die Abhängigkeit von Web-APIs und das damit verbundene Problem für Entwickler anspricht:
we’ve also learned that while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term. The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on. [..]
You might think you’re immune to this problem if you only integrate with APIs created by large players such as Twitter, Facebook and Google. But in recent years we’ve seen Twitter switch to a new authentication system, Facebook deprecate FBML, and Google discontinue several APIs. All of these changes have, or will, break existing apps.
… WeiterlesenThe end result is that developers are spending more time upgrading their software to ensure that it continues to work with web APIs they’ve integrated with, and less time adding the features and refinements that would really benefit their customers.
Shared Items im Feedreader: Es darf auch ein offener Link-Sharing-Standard sein
In meiner Analyse über die bevorstehende Abschaffung der Shared-Items-Funktion schrieb ich über die daraus entstehende Chance für GoogleReader-Clients:
Es gibt jetzt für Reeder und andere Feedreader, die auf GoogleReader als Synchronisationsplattform setzen, die einmalige Chance sich abzusetzen und Nutzer an sich zu binden, in dem sie die alte Shared-Items-Funktion clientintern kopieren. Für mich als Nutzer würde der Nutzen eines Clients, der es schafft, das erfolgreich zu implementieren, so stark steigen, dass ich GoogleReader wohl fast ausschließlich nur noch über diesen Client benutzen würde.
Das müsste das Feature beinhalten:
-Follower-Prinzip für Nutzer des Clients
-Stream aller Shared Items der Followings, inklusive der Aggregation mehrfach geteilter Inhalte
-RSS-Feed für die eigenen Shared Items, um die so gesammelten Links auf anderen Diensten integrieren zu können
Das muss natürlich kein in sich geschlossenes System sein.… Weiterlesen
