Le temps passe, et je me rends compte que je délaisse un peu ce blog. Alors voici quelques infos sur l'avancement de Kappea...
Hier soir, j'étais convié aux Trophées de l'Innovation organisés par le Technopôle de Mulhouse et la Région, car Kappea faisait partie des 18 projets innovants retenus pour concourir. Je n'ai pas eu de prix, mais ce n'est pas grave (quoique, le chèque n'aurait pas fait de mal au compte de Kappea). J'ai pu présenter le projet devant un certain nombre d'officiels et quelques banquiers, ce qui m'a permis de rôder un peu ma présentation. Il y a même un journaliste qui a dit qu'il me recontacterait, mais j'attends de voir.
A part ça, il est aussi assez probable que l'équipe de Kappea s'étoffe dans les semaines à venir : les discussions avancent bien. Un blogger dont le nom n'est pas inconnu pour les assidus du web 2.0. Un peu de patience...
Côté développement, on peut dire que je suis assez content. Les fonctionnalités se mettent en place, la charte graphique avance doucement... Sauf contre-temps majeur, je pense que la première version beta devrait sortir d'ici deux mois.
Voilà pour vous tenir un peu au courant de Kappea.
Rappel : pour ceux qui n'ont pas lu les billets précédents sur Kappea, c'est un nouveau service de petites annonces qui innove par sa stratégie de recherche. L'objectif étant bien sûr d'éviter aux utilisateurs de devoir chercher régulièrement sur plein de sites différents...
vendredi 30 mars 2007
jeudi 22 mars 2007
Ca y est Ziki s'est mis à OpenID
Oui, bon, je sais, j'ai deux jours de retard pour cette info... Toujours est-il que Jean-François l'a annoncé sur le blog : Ziki accepte la connexion via OpenId, pout ceux qui avaient déjà un compte, et devient serveur d'identité pour tous ceux qui le souhaitent.
Alors oui, c'est vrai, il n'y a pas encore des milliers de sites qui utilisent OpenId pour l'authentification, mais je ne peux qu'applaudir cela.
Les lecteurs réguliers de ce blog (ça existe ?) savaient déjà que c'était dans les tuyaux, il semble que c'est finalement venu assez vite.
Il reste juste à évangéliser un peu auprès des 8000 inscrits, et dans quelques temps vous pourrez tester votre identifiant sur Kappea (et oui, ça avance...)
Alors oui, c'est vrai, il n'y a pas encore des milliers de sites qui utilisent OpenId pour l'authentification, mais je ne peux qu'applaudir cela.
Les lecteurs réguliers de ce blog (ça existe ?) savaient déjà que c'était dans les tuyaux, il semble que c'est finalement venu assez vite.
Il reste juste à évangéliser un peu auprès des 8000 inscrits, et dans quelques temps vous pourrez tester votre identifiant sur Kappea (et oui, ça avance...)
vendredi 16 mars 2007
Petit benchmark PHP : json_encode vs serialize
Âmes non techniciennes, passez votre chemin...
Tout simplement, pendant le développement du site de Kappea, j'ai eu besoin d'une comparaison entre les fonctions json_encode() et serialize() de PHP 5.2
Les deux approches permettent de transformer des variables en chaîne de caractère, et JSON et beaucoup utilisé depuis quelques temps pour les échanges Ajax, car il est implémenté dans différents langages (contrairement à serialize() qui n'est que pour PHP).
Pour moi, l'intérêt est de sérialiser un tableau pour stocker la valeur dans un cookie. Or la fonction serialize() me renvoie une chaîne de caractère qui est environ 40% plus longue que celle de json_encode(). Le gain de place est précieux pour moi, car un cookie a une taille limite (environ 4000 caractères). Mais il ne faut pas que ce gain de place ait un important coût de temps.
J'ai donc fait un petit benchmark qui ne prétend nullement être universel, sur ma machine perso avec Ubuntu 6.10, et j'ai remarqué que json_encode() met environ... 40% de temps de plus que serialize().
Cela dit, la différence n'est tout de même pas énorme, puisque dans mon cas cela équivaut à 2,5 millionièmes de seconde de plus. Je sais que je suis un maniaque de l'optimisation, mais je crois que je vais me satisfaire de ça.
En tout cas, comme je n'avais pas trouvé de comparatif entre ces deux fonctions, je le communique (si ça peut servir à d'autres...)
Tout simplement, pendant le développement du site de Kappea, j'ai eu besoin d'une comparaison entre les fonctions json_encode() et serialize() de PHP 5.2
Les deux approches permettent de transformer des variables en chaîne de caractère, et JSON et beaucoup utilisé depuis quelques temps pour les échanges Ajax, car il est implémenté dans différents langages (contrairement à serialize() qui n'est que pour PHP).
Pour moi, l'intérêt est de sérialiser un tableau pour stocker la valeur dans un cookie. Or la fonction serialize() me renvoie une chaîne de caractère qui est environ 40% plus longue que celle de json_encode(). Le gain de place est précieux pour moi, car un cookie a une taille limite (environ 4000 caractères). Mais il ne faut pas que ce gain de place ait un important coût de temps.
J'ai donc fait un petit benchmark qui ne prétend nullement être universel, sur ma machine perso avec Ubuntu 6.10, et j'ai remarqué que json_encode() met environ... 40% de temps de plus que serialize().
Cela dit, la différence n'est tout de même pas énorme, puisque dans mon cas cela équivaut à 2,5 millionièmes de seconde de plus. Je sais que je suis un maniaque de l'optimisation, mais je crois que je vais me satisfaire de ça.
En tout cas, comme je n'avais pas trouvé de comparatif entre ces deux fonctions, je le communique (si ça peut servir à d'autres...)
lundi 5 mars 2007
Quelques soucis avec ma Fonera
Après 2 mois d'utilisation de ma Fonera généreusement offerte par Wikio, le bilan est mitigé. Non, disons plutôt qu'il n'y avait aucun problème pendant longtemps, mais depuis quelques semaines j'ai des problèmes de connexion un peu pénibles.
Régulièrement, mon PowerBook n'accède plus au réseau alors que je l'utilise. Non pas que je perde le signal, ça semble plutôt être une histoire d'adressage IP. Du coup, je suis obligé de demander un nouveau bail DHCP. Je trouve ça un peu galère.
Pourtant je ne crois pas qu'il y ait eu de mise à jour Airport récemment... Je vais peut-être essayer le firmware modifié de francofon.fr...
Quelqu'un a t'il un retour d'expérience à ce sujet ?
Régulièrement, mon PowerBook n'accède plus au réseau alors que je l'utilise. Non pas que je perde le signal, ça semble plutôt être une histoire d'adressage IP. Du coup, je suis obligé de demander un nouveau bail DHCP. Je trouve ça un peu galère.
Pourtant je ne crois pas qu'il y ait eu de mise à jour Airport récemment... Je vais peut-être essayer le firmware modifié de francofon.fr...
Quelqu'un a t'il un retour d'expérience à ce sujet ?
Ziki et OpenId, on progresse !
Certains vont peut-être penser que j'en fais un petit peu trop sur ce sujet, mais ce n'est pas grave. Je voulais juste vous partager une petite phrase du dernier mail reçu de Jean-François Ruiz :
Ce que je ne sais pas, c'est si il sera juste possible de se connecter à Ziki via OpenId, ou si ils vont implémenter un serveur d'identité (ce qui serait beaucoup plus cohérent je trouve).
Ainsi, quand Jérôme explique que pour la notion d'empreinte numérique (mise en avant d'ailleurs par Jeff), Ziki est plus pertinent que OpenId, le mieux est de dire : faisons les deux ! Mon empreinte numérique, qui recense mes productions et mes traces sur le web, peut aussi me servir d'identité pour me connecter sur de nouveaux services...
Je ne prétends pas que c'est le modèle idéal (il y a d'ailleurs encore de sérieuses questions de sécurité à régler), mais il faut bien avancer dans une direction, non ?
Tu vas être content, on va mettre en place OpenID prochainement sur Ziki (je n'ai pas de date à te donner mais ça va être fait bientot).Moi je trouve ça plutôt bien. Je soupçonne que les annonces faites par Netvibes, Microsoft, AOL et Yahoo ont eu un peu plus de poids que mes billets sur le sujet, mais ce n'est pas grave.
Ce que je ne sais pas, c'est si il sera juste possible de se connecter à Ziki via OpenId, ou si ils vont implémenter un serveur d'identité (ce qui serait beaucoup plus cohérent je trouve).
Ainsi, quand Jérôme explique que pour la notion d'empreinte numérique (mise en avant d'ailleurs par Jeff), Ziki est plus pertinent que OpenId, le mieux est de dire : faisons les deux ! Mon empreinte numérique, qui recense mes productions et mes traces sur le web, peut aussi me servir d'identité pour me connecter sur de nouveaux services...
Je ne prétends pas que c'est le modèle idéal (il y a d'ailleurs encore de sérieuses questions de sécurité à régler), mais il faut bien avancer dans une direction, non ?
jeudi 1 mars 2007
Petit mystère de MySQL
Attention : ceci est un billet plutôt technique (vous êtes prévenus dès le début).
Comme Kappea comporte une partie géolocalisation, j'ai une table cities qui comprend pour l'instant toutes les villes de France (DOM-TOM compris) avec leurs coordonnées (latitude, longitude). Il n'y pour l'instant que les villes française, mais comme je prévois d'ouvrir Kappea à d'autres pays (tiens, une révélation !), j'ai bien sûr un champ country qui est un CHAR(2) et qui est indexé.
Bien. Le décor est planté. Voyons voir ce qu'il y a de mystérieux...
Mais si on analyse la requête, ça devient surprenant...
Je crois qu'il reste encore pas mal de secrets que je n'ai pas percé dans les arcanes de MySQL.
PS: j'ai une version 5.0.32 avec la dernière Ubuntu.
Si jamais un pro de MySQL passe par là, je veux bien quelques éclairages.
Comme Kappea comporte une partie géolocalisation, j'ai une table cities qui comprend pour l'instant toutes les villes de France (DOM-TOM compris) avec leurs coordonnées (latitude, longitude). Il n'y pour l'instant que les villes française, mais comme je prévois d'ouvrir Kappea à d'autres pays (tiens, une révélation !), j'ai bien sûr un champ country qui est un CHAR(2) et qui est indexé.
Bien. Le décor est planté. Voyons voir ce qu'il y a de mystérieux...
Jusque là rien de bien spécial, puisque j'ai bien dit qu'il n'y a que des villes françaises.
mysql> SELECT COUNT(*) FROM cities;
+----------+
| COUNT(*) |
+----------+
| 38949 |
+----------+
1 row in set (0.02 sec)
mysql> SELECT COUNT(*) FROM cities WHERE country = "FR";
+----------+
| COUNT(*) |
+----------+
| 38949 |
+----------+
1 row in set (0.06 sec)
Mais si on analyse la requête, ça devient surprenant...
OK, il passe toutes les lignes en revue. Logique, puisque je ne restreint rien.
mysql> explain SELECT COUNT(*) FROM cities;
+----+-------------+--------+-------+---------------+---------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+-------+---------------+---------+---------+------+-------+-------------+
| 1 | SIMPLE | cities | index | NULL | country | 2 | NULL | 38958 | Using index |
+----+-------------+--------+-------+---------------+---------+---------+------+-------+-------------+
1 row in set (0.00 sec)
Et là, je ne comprends plus. Alors que toutes les lignes ont le champ country à la valeur "FR", la recherche par index n'en indique que 19479. Mais la requête donne le même résultat...
mysql> explain SELECT COUNT(*) FROM cities WHERE country = "FR";
+----+-------------+--------+------+---------------+---------+---------+-------+-------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+---------+---------+-------+-------+--------------------------+
| 1 | SIMPLE | cities | ref | country | country | 2 | const | 19479 | Using where; Using index |
+----+-------------+--------+------+---------------+---------+---------+-------+-------+--------------------------+
1 row in set (0.00 sec)
Je crois qu'il reste encore pas mal de secrets que je n'ai pas percé dans les arcanes de MySQL.
PS: j'ai une version 5.0.32 avec la dernière Ubuntu.
Si jamais un pro de MySQL passe par là, je veux bien quelques éclairages.
mercredi 21 février 2007
Banque d'identité, quelques compléments
Suite à mes billets sur la notion de banque d'identité comme une extension d'OpenId, voici encore quelques réflexions en vrac.
Tout d'abord, sur la difficulté de développer un tel protocole. Je ne dis pas que c'est à la portée d'un enfant de CP, mais ce n'est pas non plus insurmontable. Cela passe par une phase de modélisation des échanges, en gardant à l'esprit en permanence la sécurité, mais aussi l'optimisation des connexions entre les serveurs.
Après, il y a la question de l'adoption, par les internautes et par les réseaux sociaux. Ce qui est sûr, c'est que tant que personne ne le fait, aucun site ne l'adoptera. Aujourd'hui, je ne sais pas combien de comptes OpenId existent (je pense même que c'est dur à savoir), mais les annonces successives des derniers jours ne peuvent qu'améliorer son adoption. Pour un nouveau venu cela peut faciliter grandement la création d'un réseau social, en se focalisant sur sa spécificité, là où il va y avoir de la valeur ajoutée. Pour les réseaux existants, l'aspect décentralisé leur permet de s'ouvrir sans "perdre" leurs profils.
Et dans le monde de l'entreprise, on peut imaginer des base de données prospects qu'un nouvel employé peut enrichir très simplement, en partageant simplement ces relations depuis sa banque d'identité.
Pour l'internaute, on avance encore d'un cran dans la dimension "je suis maître de mes informations".
Bien sûr, cela concerne les personne physiques, mais aussi les organisations (je peut indiquer dans mes relations que je suis gérant de Kappea)
Le maître mot de tout cela, c'est la sécurité. Ce n'est pas pour rien que je parle de banque d'identité. Il faut fournir une sécurité optimale, ce qui n'est pas opposé à une grande liberté dans l'utilisation (rendre public son profil par exemple)
Le modèle économique ? Il n'y en a pas. Pas sur le protocole. Mais on peut en imaginer sur les services proposés par la banque d'identité.
Cela ne restera sans doute qu'un rêve, en tout cas pour quelques temps. Mais je crois qu'on va arriver un jour où l'autre à ce genre de service, car le besoin existe dès aujourd'hui.
Je n'ai pas le temps de le développer. Pas seul. Mais j'avoue que si d'autres sont intéressés par un projet de ce genre, je crois que je me laisserais tenter.
A bon entendeur...
Tout d'abord, sur la difficulté de développer un tel protocole. Je ne dis pas que c'est à la portée d'un enfant de CP, mais ce n'est pas non plus insurmontable. Cela passe par une phase de modélisation des échanges, en gardant à l'esprit en permanence la sécurité, mais aussi l'optimisation des connexions entre les serveurs.
Après, il y a la question de l'adoption, par les internautes et par les réseaux sociaux. Ce qui est sûr, c'est que tant que personne ne le fait, aucun site ne l'adoptera. Aujourd'hui, je ne sais pas combien de comptes OpenId existent (je pense même que c'est dur à savoir), mais les annonces successives des derniers jours ne peuvent qu'améliorer son adoption. Pour un nouveau venu cela peut faciliter grandement la création d'un réseau social, en se focalisant sur sa spécificité, là où il va y avoir de la valeur ajoutée. Pour les réseaux existants, l'aspect décentralisé leur permet de s'ouvrir sans "perdre" leurs profils.
Et dans le monde de l'entreprise, on peut imaginer des base de données prospects qu'un nouvel employé peut enrichir très simplement, en partageant simplement ces relations depuis sa banque d'identité.
Pour l'internaute, on avance encore d'un cran dans la dimension "je suis maître de mes informations".
Bien sûr, cela concerne les personne physiques, mais aussi les organisations (je peut indiquer dans mes relations que je suis gérant de Kappea)
Le maître mot de tout cela, c'est la sécurité. Ce n'est pas pour rien que je parle de banque d'identité. Il faut fournir une sécurité optimale, ce qui n'est pas opposé à une grande liberté dans l'utilisation (rendre public son profil par exemple)
Le modèle économique ? Il n'y en a pas. Pas sur le protocole. Mais on peut en imaginer sur les services proposés par la banque d'identité.
Cela ne restera sans doute qu'un rêve, en tout cas pour quelques temps. Mais je crois qu'on va arriver un jour où l'autre à ce genre de service, car le besoin existe dès aujourd'hui.
Je n'ai pas le temps de le développer. Pas seul. Mais j'avoue que si d'autres sont intéressés par un projet de ce genre, je crois que je me laisserais tenter.
A bon entendeur...
Banque d'identité, un exemple pour mieux comprendre
Au cas où certains ont raté le début, c'est la suite d'un billet où j'explique comment étendre le standard OpenId.
Je vous ai donc promis un exemple.
Je m'appelle MOI, et je connais trois personnes, A, B et C. Mon identifiant OpenId est http://moi.myopenid.com
Je souhaite m'inscrire sur le réseau social RS.com
Première étape : je m'inscris sur RS.com
Je donne donc mon identifiant OpenId, je suis redirigé vers ma banque d'identité qui me demande tout d'abord de m'identifier, puis m'informe que le service RS.com a sollicité des informations personnelles (nom, prénom, âge). Je décide d'accepter définitivement RS.com comme site de confiance et je lui transmets les informations demandées. Je suis alors redirigé vers le site RS.com
Jusque là, je n'ai que fait décrire le fonctionnement actuel d'OpenId.
Deuxième étape : je souhaite inviter des connaissances sur ce réseau.
Je clique donc sur inviter des connaissances, et je suis redirigé vers ma banque d'identité. Celle-ci récupère au passage la carte d'identité du site RS.com (avec entre autre le message d'invitation par défaut).
Je suis donc sur mon compte, et je cherche parmi mes connaissances celles que je souhaite inviter. Je peut compléter le message par défaut par un petit mot personnalisé.
Un message (au format XML) est alors envoyé à la banque d'identité de mon contact (B par exemple), comprenant la carte d'identité de RS.com (ou juste l'url où la trouver), mon identifiant et mon message d'invitation. Si cette personne me connaît, si je fais partie de ses relations (dans le cas où on accepte les relations déclaratives, de type Ziki ou FOAF), la banque d'identité transmet ce message à mon interlocuteur, par le biais qu'il a défini (mail, messagerie instantanée, flux RSS...).
Tout cela peut-être asynchrone, bien entendu.
Pendant ce temps là, une fois que j'ai fini d'inviter mes connaissances, je suis redirigé vers le site RS.com
On peut aussi imaginer que j'aille directement sur mon compte OpenId pour inviter des gens, et dans ce cas il faut pouvoir obtenir la fiche d'identité du site RS.com simplement (il serait d'ailleurs assez logique que celle-ci soit publique).
Troisième étape : B a accepté mon invitation.
Cela signifie qu'il s'est inscrit sur le site en indiquant à RS.com qu'il est venu suite à mon invitation. Là encore, c'est la banque d'identité qui fait le rapprochement : quand B s'inscrit sur le site, c'est à dire qu'il accepte RS.com comme site de confiance, la banque d'identité cherche dans la liste des invitations reçues celles qui concernent RS.com et les signale au site (après accord de B, bien entendu).
Le site RS.com est donc informé de la relation entre B et moi, et la stocke en cache chez lui (pour des questions de performance et de recherche dans les graphes).
Quant à moi, je suis informé que B a accepté mon invitation.
Quatrième étape : je noue de nouveaux contacts via RS.com
Si ces contacts ont eux-mêmes une identité OpenId, RS.com informe ma banque d'identité de cette nouvelle relation qui peut alors la sauvegarder dans mon espace OpenId.
Fin de l'exemple.
Le principe du stockage décentralisé qui est celui d'OpenId à l'heure actuelle permet au réseaux sociaux déjà existants de ne pas se dé-saisir de leurs informations mais au contraire d'offrir un nouveau service pour que leurs utilisateurs aillent sur d'autres sites sans avoir à tout retaper.
On devrait même pouvoir « obliger » les sites à communiquer sur demande l'ensemble des informations concernant un utilisateur. Je m'explique. Si le site RS.com gère en interne un certain nombre d'informations supplémentaires sur moi (profil, statistiques, je ne sais quoi), je dois pouvoir rapatrier en un clic ces infos (au format XML) dans mon compte OpenId.
Un point important (je ne sais pas quelle est la politique d'OpenId à l'heure actuelle) : lorsque je modifie une information personnelle (mon numéro de téléphone par exemple), ma banque d'identité doit « pousser » cette information vers tous les services qui l'utilisent pour une mise à jour complète.
J'espère que j'ai été à peu près clair...
Je vous ai donc promis un exemple.
Je m'appelle MOI, et je connais trois personnes, A, B et C. Mon identifiant OpenId est http://moi.myopenid.com
Je souhaite m'inscrire sur le réseau social RS.com
Première étape : je m'inscris sur RS.com
Je donne donc mon identifiant OpenId, je suis redirigé vers ma banque d'identité qui me demande tout d'abord de m'identifier, puis m'informe que le service RS.com a sollicité des informations personnelles (nom, prénom, âge). Je décide d'accepter définitivement RS.com comme site de confiance et je lui transmets les informations demandées. Je suis alors redirigé vers le site RS.com
Jusque là, je n'ai que fait décrire le fonctionnement actuel d'OpenId.
Deuxième étape : je souhaite inviter des connaissances sur ce réseau.
Je clique donc sur inviter des connaissances, et je suis redirigé vers ma banque d'identité. Celle-ci récupère au passage la carte d'identité du site RS.com (avec entre autre le message d'invitation par défaut).
Je suis donc sur mon compte, et je cherche parmi mes connaissances celles que je souhaite inviter. Je peut compléter le message par défaut par un petit mot personnalisé.
Un message (au format XML) est alors envoyé à la banque d'identité de mon contact (B par exemple), comprenant la carte d'identité de RS.com (ou juste l'url où la trouver), mon identifiant et mon message d'invitation. Si cette personne me connaît, si je fais partie de ses relations (dans le cas où on accepte les relations déclaratives, de type Ziki ou FOAF), la banque d'identité transmet ce message à mon interlocuteur, par le biais qu'il a défini (mail, messagerie instantanée, flux RSS...).
Tout cela peut-être asynchrone, bien entendu.
Pendant ce temps là, une fois que j'ai fini d'inviter mes connaissances, je suis redirigé vers le site RS.com
On peut aussi imaginer que j'aille directement sur mon compte OpenId pour inviter des gens, et dans ce cas il faut pouvoir obtenir la fiche d'identité du site RS.com simplement (il serait d'ailleurs assez logique que celle-ci soit publique).
Troisième étape : B a accepté mon invitation.
Cela signifie qu'il s'est inscrit sur le site en indiquant à RS.com qu'il est venu suite à mon invitation. Là encore, c'est la banque d'identité qui fait le rapprochement : quand B s'inscrit sur le site, c'est à dire qu'il accepte RS.com comme site de confiance, la banque d'identité cherche dans la liste des invitations reçues celles qui concernent RS.com et les signale au site (après accord de B, bien entendu).
Le site RS.com est donc informé de la relation entre B et moi, et la stocke en cache chez lui (pour des questions de performance et de recherche dans les graphes).
Quant à moi, je suis informé que B a accepté mon invitation.
Quatrième étape : je noue de nouveaux contacts via RS.com
Si ces contacts ont eux-mêmes une identité OpenId, RS.com informe ma banque d'identité de cette nouvelle relation qui peut alors la sauvegarder dans mon espace OpenId.
Fin de l'exemple.
Le principe du stockage décentralisé qui est celui d'OpenId à l'heure actuelle permet au réseaux sociaux déjà existants de ne pas se dé-saisir de leurs informations mais au contraire d'offrir un nouveau service pour que leurs utilisateurs aillent sur d'autres sites sans avoir à tout retaper.
On devrait même pouvoir « obliger » les sites à communiquer sur demande l'ensemble des informations concernant un utilisateur. Je m'explique. Si le site RS.com gère en interne un certain nombre d'informations supplémentaires sur moi (profil, statistiques, je ne sais quoi), je dois pouvoir rapatrier en un clic ces infos (au format XML) dans mon compte OpenId.
Un point important (je ne sais pas quelle est la politique d'OpenId à l'heure actuelle) : lorsque je modifie une information personnelle (mon numéro de téléphone par exemple), ma banque d'identité doit « pousser » cette information vers tous les services qui l'utilisent pour une mise à jour complète.
J'espère que j'ai été à peu près clair...
Une extension pour OpenId ?
Alors que les annonces en faveur d'OpenId sont de plus en plus nombreuses (après Yahoo!, Microsoft et AOL, c'est l'équipe Digg qui a annoncé le support d'ici la fin de l'année du standard d'OpenId), je vous propose un billet assez long pour imaginer ce qui pourrait être la suite d'OpenId.Edit : vu la taille, je préfère le faire en deux billets regroupés sous le tag banque d'identité.
Qu'est-ce qu'OpenId aujourd'hui ? En résumé, c'est :
- j'ai un identifiant unique (une url)
- je centralise et gère les données qui me concernent
- je donne (ou pas) l'accès à certaines de ces données aux services qui le demandent
- l'authentification (vérification du mot de passe) est déléguée à OpenId
Si certaines personnes ont des infos là-dessus, je suis preneur. Sinon, je chercherai.
En tout cas, voilà un résumé d'OpenId à l'heure actuelle. Mais maintenant, pour aller un peu plus loin, et parce que mes relations font un peu partie de mon identité, je pense qu'il faudrait pouvoir centraliser de la même manière mes relations avec d'autres internautes (ayant eux-même une URL OpenId), qualifier ces relations (types prédéfinis et tags libres), et donner accès à ces relations à différents services. C'est bien sûr le rêve de tous les boulimiques des réseaux sociaux, mais on va essayer de mieux voir comment cela peut être possible.
Une question primordiale par contre est de savoir ce qu'on considère comme relation. Est-ce unilatéral, comme sur Ziki et avec le standard FOAF (je déclare que je connais cette personne), ou faut-il que cette relation soit réciproque, c'est à dire que l'autre personne la reconnaisse aussi ? Pour l'instant, je n'ai pas tranché la question.
Mais comme rien n'est plus clair qu'un exemple, je vous propose de me suivre dans ce que pourrait être ce service de banque d'identité...
mercredi 14 février 2007
Kappea, c'est parti !
Ca y est, on a signé les statuts. Kappea démarre donc officiellement. C'est l'aboutissement de nombreux mois de préparation, questions, schémas, discussions, projets de business-model... Mais c'est surtout le début d'une sacrée aventure, que je vous raconterai ici au fur et à mesure.
Une affaire à suivre...
Une affaire à suivre...
Inscription à :
Articles (Atom)
