Schlagwort

rivva

7.1.2008

Zu Gast beim
Elektrischen Reporter

Die Alpha-Geeks sind die ersten, die die Informationsflut spüren und nach Mechanismen suchen, ihr zu entkommen, meinte ich neulich vor Mario Sixtus laufenden Kameras. Heute ist die Ausgabe erschienen:

YouTube

Hervorheben möchte ich auch die Folgen mit Peter Glaser, (Teil 2), Lawrence Lessig, (Teil 2), Bruce Sterling und – absolutes Prachtstück – Cory Doctorow.

16.8.2007

Rivva, vier Supernasen
und das Förderland

Kürzlich stand ich 2x Rede & Antwort zu Rivva:

Letzte Woche hatte ich das Vergnügen, von Mario Sixtus, Nico Lumma + Sebastian Keil zum Klönschnack im Vier-Nasen-tanken-Super-Podcast eingeladen zu werden: MP3 (25:15 Min, 8.7 MB)

Und heute ist noch ein Interview im Förderland erschienen:

Interview fürs Förderland

11.3.2007

Rivva gestartet

Am 3. habe ich still und heimlich Rivva gelauncht: einen Meme Tracker, der die deutschsprachige Bloglandschaft nach den aktuellen Top-Themen und Diskussionen – kurz: dem Zeitgeist – durchforstet. Mehr zu den Hintergründen auf dem Rivva-Blog

Rivva-Screenshot

11.7.2007

Rails Rivva

Rails-Logo

Wollte mal sehen, ob sich Rivva auch dazu eignet, z. B. RoR-Blogs zu verfolgen. Das Ergebnis haut mich noch nicht um, doch selbst Rivva #1 hat eine Weile zum Einschwingen gebraucht … Nun denn: http://rails.rivva.de

23.3.2007

Gespräch mit einem Blogpiloten

Interview für die Blogpiloten Noch ein Interview: Diese Woche mit Thomas Gigold über Rivva, Ruby on Rails und das neue Web.

zu lesen bei den Blogpiloten

In other News: Mit Joyent Slingshot sollen Ruby-on-Rails-Apps offline laufen und à la Apollo die Brücke zum Desktop schlagen. Game Changer!

7.7.2008

Gnip, bitte nur ein Ping

Gnip-Logo

Hierzulande viel zu wenig Beachtung gefunden hat in meinen Augen der Stapellauf von Gnip letzte Woche.

Selten kommt ein neuer Service daher, der das Remixen und Mæshen so stark vereinfacht und damit weitergehend demokratisieren wird. Letztes Jahr war es Yahoo! Pipes, 2008 könnte es Gnip werden. War das Motto der Pipes (and Filters) jedoch Mashups für den Rest von uns, werden die meisten Menschen Gnip nie zu Gesicht bekommen. Jedenfalls solange Gnip nur seinen Job erledigt. Denn Gnip will stromaufwärts notwendige moderne Infrastruktur 2.0 bereitstellen.

Was macht Gnip?

Gnip möchte als Nachrichtenbus agieren für Micro-Content aller Art aus allen möglichen Social-Media-Plattformen. Man möchte den Datenfluss zwischen diversen Anwendungen so einfach und portabel wie möglich gestalten und zwar für die Produzentenseite gleichermaßen wie für die anschließenden Konsumenten.

In anderen Worten: Gnip will uns ermächtigen, FriendFeed innerhalb von einem Nachmittag nachzuprogrammieren.

Warum das heutige Aggregationsmodell für Social Media nicht skaliert

Wer heute angebotene Dienste über Web-/REST-APIs oder RSS-/Atom-/JSON-Feeds remixen möchte (grundlegendes zum Thema Mashups), sieht sich folgendem Dilemma ausgesetzt:

  • Wir können Datenquellen entweder relativ häufig pollen, um von etwaigen Änderungen schnellstmöglich zu profitieren.
  • Oder uns und unserem Gegenüber eine riesige Menge redundanter Anfragen und damit enorme Bandbreite sparen, indem wir größere Latenzzeiten zwischen unseren Anfragen einhalten.

Der Kompromiss besteht zwischen wünschenswerter Aktualität und hoher Informationseffizienz. Ein Twitter-Status, dass ein paar Freunde gerade am Elbstrand Bier + Sonne tanken, ist beispielsweise nicht mehr von besonders hohem Wert, wenn wir die Nachricht zu spät erhalten. Die Gefahr im Gegenzug ist aber, den Anbieter durch eine zu hohe Polling-Frequenz Hast Du wat Neues für mich? … Hey, schon wat Neues? … Jetzt? – jetzt vielleicht wat Neues? zu überlasten, um dann wahrscheinlich gedrosselt oder womöglich sogar gesperrt zu werden. Beide Seiten verlieren! Daten wollen reisen, Daten wollen frei sein.

Die Crux ist also, die Polling-Frequenz der Änderungsrate auf der Gegenseite anzunähern: einerseits nichts zu verpassen, andererseits aber auch nicht zu drängeln.

Diese Problematik stellt sich bei News-Aggregatoren wie meinem Rivva genauso wie bei Lifestreaming-Diensten wie FriendFeed oder beim ganz normalen Abholen und Lesen der eigenen Feed-Abos. Doch das Problem wächst exponentiell … denn sowohl die Menge remixbarer Quellen als auch die Anzahl vermanschbarer Aktivitätsströme werden über die nächsten Jahre in wohl dramatischer Weise zunehmen.

In FriendFeed lassen sich heute beispielsweise nur 41 der populärsten Dienste einspeisen. Das sind nicht nur viel zu wenig Möglichkeiten, nein, die Sicht ist auch noch viel zu US-zentrisch und schon in einem Jahr wird es Hunderte weiterer relevanter Services geben. Wenn uns das Kreuzprodukt aus x Diensten * y Nutzer * z Updates pro Stunde hier keinen Strich durch die Rechnung machen würde, bräuchte es sowas wie Gnip nicht. Und mindestens einstündliche Updates sind für viele Anwendungen noch das absolute Minimum. Fürs massentaugliche Live-Web versagt dieses Modell ziemlich rasch.

Invertierung der Datenströme – von Pull zu Push

Gnip nun stellt sich als Mittelsmann zwischen die wertschaffenden Content-Plattformen und die davon wertschöpfenden Media-Aggregatoren. Zwei der Launch-Partner sind zum Beispiel Digg und Plaxo: Diggt jetzt jemand eine Story, soll diese Aktivität binnen 60 Sekunden bei Plaxo Pulse erscheinen.

Poll vs. Push

Möglich werden die Nahezu-Echtzeit-Updates, indem man dem Pub/Sub-Modell folgt: Gnip sammelt die Aktivitätsströme an zunächst zentral organisierter Stelle (später solls mal dezentral werden) und verteilt sie sofort an seine Liste von Empfängern.

Die Notifikation kann produzenten- wie konsumentenseitig via Pull oder Push erfolgen. Insbesondere im Push-Mechanismus sehe ich die ermöglichende Schlüsseltechnologie für diverse neue Anwendungen, vor allem aber auch für kleinere Dienste wie Rivva, die sich eine kostspieligere Infrastruktur auch gar nicht leisten könnten.

Bridging zwischen verschiedenen Protokollen und Formaten

Gut gefällt mir dabei die Protokollbrücke: wie man als Quasi-Babelfisch zwischen verschiedenen Ein-/Ausgabe-Formaten und -Protokollen übersetzt: Zur Eingabe dienen XMPP, Atom, RSS und REST. Zur Ausgabe kommt derzeit nur Atom via REST zum Tragen, der Rest soll zu einem späteren Zeitpunkt folgen.

Protokollbrücke

Getreu dem Motto Release Early hat man sich zum Start auf die reine Benachrichtigung zwischen Punkt A und Punkt B konzentriert, der tatsächliche Datenaustausch soll später kommen.

Hohe Datenportabilität durch standardisierte Metadaten

Weitere Karma-Punkte sammelt Gnip für die anbieterübergreifende Standardisierung der verschiedenen Semantiken in den Activity Streams. Hier war man so gut beraten, Chris Messina und seine Arbeit im DiSo-Projekt zu integrieren. Die Gnip API beschreibt, wie unterschiedliche Datenformate nach einer XSLT in einem normalisierten Activity XML konsumiert werden können.

Sehr schön, wie die Gnips auf Standards setzen, wo immer dies möglich war. Kein Mashup-Entwickler dieser Welt wirds vermissen, für jeden anzubindenden Dienst eine kleine Extrawurst programmieren zu müssen.

Summa Summarum

Alles in allem könnte Gnip vielleicht zu so zentraler Wichtigkeit gelangen wie der Push Notification Service fürs iPhone. Die Sterne stehen gut.

Um das Akamai für Web-Services zu werden, müssen sie natürlich noch unter Beweis stellen, dass sie auch hohe Lastspitzen mühelos überstehen. Look Ma, no SQL database zeugt von einem guten Omen.

Showstopper könnte allerdings die rechtliche und insbesondere politische Sachlage werden. APIs sind der neue Klebstoff. Wer sein API in die Hände eines Dritten gibt, tritt damit auch einen Großteil seiner Kontrolle darüber ab. Dass Twitter diesen Schritt machen wird, glaube ich mal nicht.

Update: bin begeistert, Twitter spielt wider Erwarten doch Gnip Gnop

Update #2: Sebastian Keil, Marcel Weiß und ich haben Gnip auf Kanal 14 näher analysiert.