Summary:
I'd like to have a meta-community-service that allows me e.g. to add all my current contacts also into a new network. So something that does 'add all my LinkedIn/Mybloglog contacts who have a twitter account to my Twitter friends'.
Nein, natürlich nicht Twitter sondern ähnliche Presencedienste - teilweise noch ohne SMSfunktion.
Einerseits ist die Funktionalität von Twitter so trivial, dass sie extrem schnell nachbaubar ist.
Andererseits ist sie auch so simpel, dass sie ggf. nicht skaliert, und optimiert werden muss.
Drittens ist sie so gestaltet, dass man an sich ohnehin seine bestehenden Netzwerkkontakte drin haben will und nicht nochmals hergehen will und alles nochmal einpflegen.
An sich führt das zu einer bestehenden Diskussion:
wann kriege ich überall APIs dergestalt, dass ich in einem 'Metanetzwerk' sagen kann:
'Bitte binde alle meine bestehenden Kontakte auch in mein xy-Netzwerk ein.'
Also: Knopfdruck und alle Xing- oder MyblogLog-Kontakte werden z.B. bei Twitter abonniert.
Überhaupt sind Metadienst an sich das, was die wlet jett noch braucht,d enn we will in zwei dutzend Netzwerken Mitglied sein; bzw.: wer KANN da aktiv sein?
Und: Netzwerke ohne möglichst offene API werden dann eh marginal sein... (wobei, wie wir wissen, am Rand jede Menge Platz ist ;) )
An sowas würd ich gern arbeiten.
via
Bebo Clones Twitter, Blatantly
I'd like to have a meta-community-service that allows me e.g. to add all my current contacts also into a new network. So something that does 'add all my LinkedIn/Mybloglog contacts who have a twitter account to my Twitter friends'.
Nein, natürlich nicht Twitter sondern ähnliche Presencedienste - teilweise noch ohne SMSfunktion.
Einerseits ist die Funktionalität von Twitter so trivial, dass sie extrem schnell nachbaubar ist.
Andererseits ist sie auch so simpel, dass sie ggf. nicht skaliert, und optimiert werden muss.
Drittens ist sie so gestaltet, dass man an sich ohnehin seine bestehenden Netzwerkkontakte drin haben will und nicht nochmals hergehen will und alles nochmal einpflegen.
An sich führt das zu einer bestehenden Diskussion:
wann kriege ich überall APIs dergestalt, dass ich in einem 'Metanetzwerk' sagen kann:
'Bitte binde alle meine bestehenden Kontakte auch in mein xy-Netzwerk ein.'
Also: Knopfdruck und alle Xing- oder MyblogLog-Kontakte werden z.B. bei Twitter abonniert.
Überhaupt sind Metadienst an sich das, was die wlet jett noch braucht,d enn we will in zwei dutzend Netzwerken Mitglied sein; bzw.: wer KANN da aktiv sein?
Und: Netzwerke ohne möglichst offene API werden dann eh marginal sein... (wobei, wie wir wissen, am Rand jede Menge Platz ist ;) )
An sowas würd ich gern arbeiten.
via
Bebo Clones Twitter, Blatantly
Noch schöner wäre es, wenn nicht ein Network die Kontakte von einem anderen Network importieren müsste, sondern wenn meine Kontakte zentral vorliegen würden, z.B. in Form von Mikroformaten (hCard, XFN, FOAF).
AntwortenLöschenVorteil wäre, dass ich zusätzlich ein zentrales Adressbuch hätte. ClaimID.com und Videntity.org gehen schon in so eine Richtung, sind aber noch lange nicht perfekt.
Aber warum zentral und nicht dynamisch verteilt...?
AntwortenLöschenIch glaub ja auch dass p2p noch nicht ausgereitzt ist...
Ich bin mir nicht ganz sicher, was Du mit dynamisch verteilt meinst. Aber ich glaube ich habe auch einen Satz in meinem Kommentar vergessen. ;)
AntwortenLöschenWenn ich zentral irgendwo ein Adressbuch hätte, könnte ich es eben als genaus das benutzen: als Adressbuch.
Registriere ich mich jetzt bei Xing, könnten meine Kontakte von dort importiert werden. Registriere ich mich auch noch bei Twitter werden sie eben auch aus meinem Adressbuch importiert. Wenn ich Dich richtig verstanden habe, würdest du bei der Anmeldung bei Twitter den direkten Import aus Xing vorziehen.
Aber egal wie man es löst, das Adressbuch wäre in beiden Fällen dezentral verteilt. In meinem Beispiel an drei Stellen im Netz, bei Dir an zwei Stellen.
Oder ich habe Dich jetzt überhaupt nicht verstanden. Dann schiebe ich das aber auf Sonntag Vormittag. ;)
"Andererseits ist sie auch so simpel, dass sie ggf. nicht skaliert, und optimiert werden muss."
AntwortenLöschenohohohohoh :D. Was glaubst Du, warum Twitter so oft so langsam ist? Die sind massiv am rotieren um das am laufen zu halten. Und da Twitter die mit Abstand größte App auf Ruby-Basis ist, schaut da gerade die ganze Welt zu wie gut das skalieren funktioniert mit ruby.
Gerade mehr Nutzer bedeuten bei so einem Echtzeitsystem mehr Zugriffe, sehr viel mehr. Ich denke, das steigt da bestimmt schon fast exponentiell.
Ich nutze Twitter intensiv und als Contentquelle fürs Bloggen ;) ich weiss wos holpert.
LöschenMit 'nicht skaliert' meine ich: auf der Seite der aufnehmenden Leser ;)
Technik ist nir schnurz, Kommunikation ist relevant ;)
jetzt merk ich erst, dass du den satz ggf falsch verstandne hast. D.h.
Löschen'sie ist so simpel, dass sie nicht skaliert - und muss daher optimiert werden'
das meinte ich aber eher im kommunikativen denn im technischen Sinne. Wenn Scoble 1000+ friends auch 'folgt' dann....
Noch besser waere, die Netzwerke wuerden untereinander APIs anbieten. D. h. ich muss nicht erst meine Daten aus Xing exportieren (dass Expoprt dort nicht angeboten wird, hat sicher einen marktstrategischen Hintergrund), sondern kann einen Xing-Kontakt mit einem bei LinkedIn direkt vernetzen.
AntwortenLöschenYep. Ich meinte an sich auch keinen Export sondern eine Vernetzung. D.h. dass ich z.B. via Twitterw as schicke und es ggf. bei jaiku 'vons elbst' ankommt (sofern ich das so will und mir nicht erst komplexe Feedkonstruktionen bauen muss...)
AntwortenLöschenAh, jetzt verstehe ich Dich, Oliver. Geht dann aber natürlich weit über Kontakte hinaus. Das sehe ich auf absehbare Zeit (1-2 Jahre) nicht kommen.
LöschenSo eine Vernetzung wird kommen. Das wird aber noch Jahre, wenn nicht Jahrzehnte dauern.
AntwortenLöschenIch denke, das ist hauptsächlich eine Frage des Marktes und dessen Adaptionsfähigkeit. Eine so enge Verzahnung werden kleine Netzwerke irgendwann implementieren. Und dann heißt es: Netzwerkeffekt(viele Kleine) gegen Netzwerkeffekt(wenige Große).