OpenUDC assumptions
26 views
Skip to first unread message
Matthieu Vergne
May 3, 2013, 1:20:28 PM5/3/13
to open-udc
I think that some things need to be clarified on the architecture of OpenUDC. Maybe the initial authors will hate me because of this remark, but I do not say here that you are doing a mistake (it is a matter of choice), so do not take it personally please {'^_^}.
The TRM does not introduce any notion of trust between the individuals, but trust between the individual and the currency. So the web of trust is something introduced by OpenUDC, not the TRM. So OpenUDC does not just implement the TRM, but already make some restrictive assumptions (here on the management of the individuals' trust). I do not say it is bad, but the point is to know which assumptions OpenUDC actually add.
I think personally that the added assumptions can be implemented as plugins, because the TRM does not depend on it. And maybe in such a case OpenUDC could have a better success, in the sense that people not motivated by the web of trust provided in OpenUDC (or simply who wants to try something else) can just use what they want, the core being TRM-based only.
The TRM does not introduce any notion of trust between the individuals, but trust between the individual and the currency. So the web of trust is something introduced by OpenUDC, not the TRM. So OpenUDC does not just implement the TRM, but already make some restrictive assumptions (here on the management of the individuals' trust). I do not say it is bad, but the point is to know which assumptions OpenUDC actually add.
I think personally that the added assumptions can be implemented as plugins, because the TRM does not depend on it. And maybe in such a case OpenUDC could have a better success, in the sense that people not motivated by the web of trust provided in OpenUDC (or simply who wants to try something else) can just use what they want, the core being TRM-based only.
I think a plugin-based architecture could be a good idea, especially because the TRM is not yet known by everyone, so I expect to see a lot of different ideas completing it on different dimensions (we have already seen some in this mailing list). It could be also a way to better segment and prioritize the work.
Stephane Laborde
May 3, 2013, 1:49:23 PM5/3/13
to open...@googlegroups.com
This is right. You can observe a TRM based centralised project here : http://merome.net/blog/index.php?post/2013/01/16/Monnaie-M
There is not one unique way to developp a project compatible with TRM, but each of it will add some restrictive assumption.
You cannot think it can exist a minimal TRM based project (core TRM program) because of the Theorem "there is not a minimal program" : study http://fr.wikipedia.org/wiki/Complexit%C3%A9_de_Kolmogorov and study also http://fr.wikipedia.org/wiki/Omega_de_Chaitin
Generally think about Gödel Theorems : http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8mes_d%27incompl%C3%A9tude_de_G%C3%B6del
So I understand your idea, but there is no theoretical answer to it. You canl only try to find an intuitive solution you can developp, and OpenUDC is such an inuitive solution. We can say "OpenUDC is consistant relatively with TRM".
There is not one unique way to developp a project compatible with TRM, but each of it will add some restrictive assumption.
You cannot think it can exist a minimal TRM based project (core TRM program) because of the Theorem "there is not a minimal program" : study http://fr.wikipedia.org/wiki/Complexit%C3%A9_de_Kolmogorov and study also http://fr.wikipedia.org/wiki/Omega_de_Chaitin
Generally think about Gödel Theorems : http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8mes_d%27incompl%C3%A9tude_de_G%C3%B6del
So I understand your idea, but there is no theoretical answer to it. You canl only try to find an intuitive solution you can developp, and OpenUDC is such an inuitive solution. We can say "OpenUDC is consistant relatively with TRM".
Matthieu Vergne
May 3, 2013, 2:26:07 PM5/3/13
to open-udc
I am not speaking about philosophical stuff {'^_^} but about design, considering my experience and knowledge as an engineer and researcher in software engineering: the TRM describes some concepts and, based on these concepts, build a theory. The TRM does not depend on the web of trust, while the opposite is true (or at least seems so), what can be translated in an architecture where the TRM part is implemented in a specific module, the web of trust part in another module, and the latter uses the former. If both depend on each other, it makes sense to keep them together, otherwise it is generally commonly agreed that more you design consistent modules independently, clearer is your architecture and easier is its maintenance. I take the perspective of an engineer here {'^_^}. If it is not segmented, we take the risk to have a program which is so monolithic that after some years it will go to trash because it will be unmaintainable because you cannot change a single line of code without reviewing all the code to find its influences.
Now, I just read the about page of OpenUDC:
"But the TRM is not a technical description of how such a money system can be developed concretely, and so the choices of OpenUDC technical tools are totally independent of the TRM."
"But the TRM is not a technical description of how such a money system can be developed concretely, and so the choices of OpenUDC technical tools are totally independent of the TRM."
Of course it is not a technical description, but using an object oriented approach you can translate it in a UML diagram which gives you a design of a program implementing it, and only the TRM. Then it can be full of interfaces, because there is no details about how to compute some elements, but then the core can be extended to design the details in different ways, OpenUDC being one of them and adding the concept of web of trust. I am used to do this kind of design, and I would like to do it here, I just do not know if I will find time, because it is generally not quick to do and I am busy (like everyone). However the TRM is simple, so I think it can be addressed quite easily, just need some time.
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes open-udc.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse open-udc+u...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
Stephane Laborde
May 3, 2013, 2:47:53 PM5/3/13
to open...@googlegroups.com
I understand what you mean.
jbar will precrise that : as it is designed OpenUDC makes clear separation between Web of Trust on one part and money database on the other part. So Web of Trust can be replaced by other way of recognition of living members, if needed by an evolution.
jbar will precrise that : as it is designed OpenUDC makes clear separation between Web of Trust on one part and money database on the other part. So Web of Trust can be replaced by other way of recognition of living members, if needed by an evolution.
Cédric Moreau
May 3, 2013, 4:39:52 PM5/3/13
to open...@googlegroups.com
I think you cannot implement the TRM just like a program, because the TRM does not describes a program, it describes a (non technical) system.
That is why implementing TRM means giving the details of implementation, hence what are individuals and what is money. You can't separate the TRM from its details to make an implementation (i.e. make a "TRM" module and a "WoT" module and separate them).
And if, in the future, you do change those details, you are actually changing of system : i.e. making a fork.
Matthieu Vergne
May 3, 2013, 5:26:09 PM5/3/13
to open-udc
Well, if by program you mean something able to run alone, then yes, I agree. What I have in mind is a library (in Java, a set of interfaces with a few abstract classes which provide the basic functions) that you can use in your program to make something running. Probably my vocabulary is misleading {'^_^}. For instance, supposing you want to implement it in Java or C++ or with any other OO approach, nothing forbid you to make a class CurrencyManager, a class MonetaryZone, a class Individual and provide some functions in them, such as add an individual in the monetary zone, create currency and share it equally among the individuals in the zone, and so on. I simplify, probably this example would be more for a simulator than an actual system to manage it IRL, but the idea is there : non-technical does not mean anti-technical, it only means that there is technical parts which are missing. A source code is not different to a formalization.
Anyway, Stéphane has clarified my point {^_^}.I think you cannot implement the TRM just like a program, because the TRM does not describes a program, it describes a (non technical) system.That is why implementing TRM means giving the details of implementation, hence what are individuals and what is money. You can't separate the TRM from its details to make an implementation (i.e. make a "TRM" module and a "WoT" module and separate them).And if, in the future, you do change those details, you are actually changing of system : i.e. making a fork.
--
Arnaud Faisan
Dec 19, 2013, 8:36:37 AM12/19/13
to ope...@googlegroups.com, open-udc
I agree with Matthieu Vergne.
Divide and rule : I see the WoT part of OpenUDC as a decentralized identification system. I think such a system could be useful outside OpenUDC scope. So, I think that part could be a project on its own, what do you think ?
Stéphane Laborde
Dec 19, 2013, 8:41:20 AM12/19/13
to ope...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Arnaud,
What is your blog, website or projects you work on ?
Le 19/12/2013 14:36, Arnaud Faisan a �crit :
>
>
> Le vendredi 3 mai 2013 23:26:09 UTC+2, Matthieu Vergne a �crit :
>
>
> 2013/5/3 C�dric Moreau <cem.m...@gmail.com <javascript:>>
> Groupes open-udc. Pour vous d�sabonner de ce groupe et ne plus
> recevoir d'e-mails le concernant, envoyez un e-mail � l'adresse
> open-udc+u...@googlegroups.com <javascript:>. Pour plus d'options,
>
>
>
>
> -- OpenUDC aims to provide a open standard for Universal Dividend
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> open...@muc.jappix.com. --- You received this message because you
> are subscribed to the Google Groups "OpenUDC" group. To
> unsubscribe from this group and stop receiving emails from it, send
> an email to openudc+u...@googlegroups.com. For more options,
> visit https://groups.google.com/groups/opt_out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJSsvd+AAoJELdo2ekCUDkj7tUH/jMoAepWJp/C3T68bMchF8Wa
tJzAE0lHENqXsYqnj7AlNkIRJ9G8bvCTbUwyW5P+rbnV3UcxrMXmmBG4m+0nxBBC
QIHuXMZCqJT5CLMFu4lO0WVzlFwaW50uJiN187p6X9WDvw6cdbsr82YRP6EkcF4J
9u0QODnl5rHKtKYwzci7BBwUjpoibym2JEnmcmv0pnfT0BdQCeGbPcKdmr/zcmyF
+isAY0yalmlqMKqysWszXE9q5hh/AfS6Ii6YEUei82RvRaOVRcJ8f3xKg+V4GA9U
NYHdNiJWFmjv1i3cBJe39sqCvBY7JFjCX2oOpgz3UTcRqHCptP4aRd6P+HL0M+0=
=5XUW
-----END PGP SIGNATURE-----
Hash: SHA256
Hi Arnaud,
What is your blog, website or projects you work on ?
Le 19/12/2013 14:36, Arnaud Faisan a �crit :
> I agree with Matthieu Vergne.
>
>
> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> identification system. I think such asystem could be usefuloutside
> OpenUDC scope. So, I think that partcould be a project on its
>
>
> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> identification system. I think such asystem could be usefuloutside
> own, what do you think ?
It is.
>
>
> Le vendredi 3 mai 2013 23:26:09 UTC+2, Matthieu Vergne a �crit :
>
> Well, if by program you mean something able to run alone, then yes,
> I agree. What I have in mind is a library (in Java, a set of
> interfaces with a few abstract classes which provide the basic
> functions) that you can use in your program to make something
> running. Probably my vocabulary is misleading {'^_^}. For instance,
> supposing you want to implement it in Java or C++ or with any other
> OO approach, nothing forbid you to make a class CurrencyManager, a
> class MonetaryZone, a class Individual and provide some functions
> in them, such as add an individual in the monetary zone, create
> currency and share it equally among the individuals in the zone,
> and so on. I simplify, probably this example would be more for a
> simulator than an actual system to manage it IRL, but the idea is
> there : non-technical does not mean anti-technical, it only means
> that there is technical parts which are missing. A source code is
> not different to a formalization.
>
> Anyway, St�phane has clarified my point {^_^}.
> Well, if by program you mean something able to run alone, then yes,
> I agree. What I have in mind is a library (in Java, a set of
> interfaces with a few abstract classes which provide the basic
> functions) that you can use in your program to make something
> running. Probably my vocabulary is misleading {'^_^}. For instance,
> supposing you want to implement it in Java or C++ or with any other
> OO approach, nothing forbid you to make a class CurrencyManager, a
> class MonetaryZone, a class Individual and provide some functions
> in them, such as add an individual in the monetary zone, create
> currency and share it equally among the individuals in the zone,
> and so on. I simplify, probably this example would be more for a
> simulator than an actual system to manage it IRL, but the idea is
> there : non-technical does not mean anti-technical, it only means
> that there is technical parts which are missing. A source code is
> not different to a formalization.
>
>
>
> 2013/5/3 C�dric Moreau <cem.m...@gmail.com <javascript:>>
>
> I think you cannot implement the TRM just like a program, because
> the TRM does not describes a program, it describes a (non
> technical) system.
>
> That is why implementing TRM means giving the details of
> implementation, hence what are individuals and what is money. You
> can't separate the TRM from its details to make an implementation
> (i.e. make a "TRM" module and a "WoT" module and separate them).
>
> And if, in the future, you do change those details, you are
> actually changing of system : i.e. making a fork.
>
> -- Vous recevez ce message, car vous �tes abonn� au groupe Google
> I think you cannot implement the TRM just like a program, because
> the TRM does not describes a program, it describes a (non
> technical) system.
>
> That is why implementing TRM means giving the details of
> implementation, hence what are individuals and what is money. You
> can't separate the TRM from its details to make an implementation
> (i.e. make a "TRM" module and a "WoT" module and separate them).
>
> And if, in the future, you do change those details, you are
> actually changing of system : i.e. making a fork.
>
> Groupes open-udc. Pour vous d�sabonner de ce groupe et ne plus
> recevoir d'e-mails le concernant, envoyez un e-mail � l'adresse
> open-udc+u...@googlegroups.com <javascript:>. Pour plus d'options,
> visitez le site https://groups.google.com/groups/opt_out
> <https://groups.google.com/groups/opt_out> .
>
>
>
>
> -- OpenUDC aims to provide a open standard for Universal Dividend
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> open...@muc.jappix.com. --- You received this message because you
> are subscribed to the Google Groups "OpenUDC" group. To
> unsubscribe from this group and stop receiving emails from it, send
> an email to openudc+u...@googlegroups.com. For more options,
> visit https://groups.google.com/groups/opt_out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJSsvd+AAoJELdo2ekCUDkj7tUH/jMoAepWJp/C3T68bMchF8Wa
tJzAE0lHENqXsYqnj7AlNkIRJ9G8bvCTbUwyW5P+rbnV3UcxrMXmmBG4m+0nxBBC
QIHuXMZCqJT5CLMFu4lO0WVzlFwaW50uJiN187p6X9WDvw6cdbsr82YRP6EkcF4J
9u0QODnl5rHKtKYwzci7BBwUjpoibym2JEnmcmv0pnfT0BdQCeGbPcKdmr/zcmyF
+isAY0yalmlqMKqysWszXE9q5hh/AfS6Ii6YEUei82RvRaOVRcJ8f3xKg+V4GA9U
NYHdNiJWFmjv1i3cBJe39sqCvBY7JFjCX2oOpgz3UTcRqHCptP4aRd6P+HL0M+0=
=5XUW
-----END PGP SIGNATURE-----
Matthieu Vergne
Dec 19, 2013, 9:02:22 AM12/19/13
to OpenUDC
2013/12/19 Arnaud Faisan <arnaud...@gmail.com>
Divide and rule : I see the WoT part of OpenUDC as a decentralized identification system. I think such a system could be useful outside OpenUDC scope. So, I think that part could be a project on its own, what do you think ?
I think it makes sense. But as you say it, it could be a project on its own, and so out of the scope of OpenUDC. Then it could deliver a library that OpenUDC could use if they want (otherwise they can use their own implementation, as they do now). If you intend to develop such a project, keep in touch with me {^_^}. I would like to make a TRM lib in Java, but if someone else would like to make one in C/C++, maybe it could be of interest for OpenUDC people. A discussion as started on the forum of Monnaie M to clarify the formalisation of the TRM :
http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
If you provide your own perspective, we could have a more comprehensive interpretation. I think this formalisation is a necessary step before to work on a given implementation.
Arnaud Faisan
Dec 19, 2013, 9:15:06 AM12/19/13
to ope...@googlegroups.com
Hi MrGaluel,
I am a software engineer but I have no blog, no website, no personal projects. However, I am convinced about the ideas presented in the TRM and I would like to contribute so this is my project now!
Le jeudi 19 décembre 2013 14:41:20 UTC+1, MrGaluel a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Arnaud,
What is your blog, website or projects you work on ?
Le 19/12/2013 14:36, Arnaud Faisan a �crit :
> I agree with Matthieu Vergne.
>
>
> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> identification system. I think such asystem could be usefuloutside
> OpenUDC scope. So, I think that partcould be a project on its
> own, what do you think ?
It is.
>
>
> Le vendredi 3 mai 2013 23:26:09 UTC+2, Matthieu Vergne a �crit :
>
> Well, if by program you mean something able to run alone, then yes,
> I agree. What I have in mind is a library (in Java, a set of
> interfaces with a few abstract classes which provide the basic
> functions) that you can use in your program to make something
> running. Probably my vocabulary is misleading {'^_^}. For instance,
> supposing you want to implement it in Java or C++ or with any other
> OO approach, nothing forbid you to make a class CurrencyManager, a
> class MonetaryZone, a class Individual and provide some functions
> in them, such as add an individual in the monetary zone, create
> currency and share it equally among the individuals in the zone,
> and so on. I simplify, probably this example would be more for a
> simulator than an actual system to manage it IRL, but the idea is
> there : non-technical does not mean anti-technical, it only means
> that there is technical parts which are missing. A source code is
> not different to a formalization.
>
> Anyway, St�phane has clarified my point {^_^}.
>
>
> 2013/5/3 C�dric Moreau <cem.m...@gmail.com <javascript:>>
>
> I think you cannot implement the TRM just like a program, because
> the TRM does not describes a program, it describes a (non
> technical) system.
>
> That is why implementing TRM means giving the details of
> implementation, hence what are individuals and what is money. You
> can't separate the TRM from its details to make an implementation
> (i.e. make a "TRM" module and a "WoT" module and separate them).
>
> And if, in the future, you do change those details, you are
> actually changing of system : i.e. making a fork.
>
> -- Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes open-udc. Pour vous d�sabonner de ce groupe et ne plus
> recevoir d'e-mails le concernant, envoyez un e-mail � l'adresse
Stéphane Laborde
Dec 19, 2013, 9:28:14 AM12/19/13
to ope...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 19/12/2013 15:15, Arnaud Faisan a �crit :
Hash: SHA256
> Hi MrGaluel,
>
> I am a software engineer but I have no blog, no website, no
> personal projects. However, I am convinced about the ideas
> presented in the TRM and I would like to contribute so /this/ is my
>
> I am a software engineer but I have no blog, no website, no
> personal projects. However, I am convinced about the ideas
> project now!
>
Welcome to OpenUDC developpers team mailing list !
We don't speak at all about TRM here as Matthieu talked about, (if you
are still interested by TRM and money theories in general you should
go to www.creationmonetaire.info or elsewhere), but only about OpenUDC
tools as they were first defined and still developped by jbar, from
OpenUDC 0.3 to next OpenUDC 0.4 version.
You can also join our XMPP/Jabber chat Room : open...@muc.jappix.com
You are fully right OpenPGP is an external tool, and OpenUDC work with
and above it, however it needs little bit improvements to be used for
OpenUDC (separated WoT with UDID2 identififation).
You can ask technical questions about LUD / LUDD / GLUD (you can read
the blog first, then the project.openudc.org presentation, and then in
github the technical specifications).
We prepare also our next 3rd OpenUDC meeting in April 2014, probably
in Paris, but organisation is still open, so it could be in another
place if we receive propositions.
Welcome in,
Happy coding :)
?aluel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJSswJ9AAoJELdo2ekCUDkjwq0H/30gENzbMjqtRzXCh+kN7uGQ
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
vk1krNGgvVA//jBAngIaJDj2PhMaqywjMqeUGkk4YV3JeJP0fPmYQHMg3Uuhvae8
C0iIUeEAxKhtiuwNjvHlMHf/+1K1WQ5dvvYH2EGiZvNNrLtv+me2m8x5kzzKfzfh
yzAno5RIAQ/LEeSCtE6S5QFhaUvW6ewnuRVsN4Fe9+MU7WxZVLuReyuQTe/k6wrH
qpIqC4kSgMT2yPnw3dY81vvnylY2t2Roqa7KXFS7ulN21ZpeJk0WbFoIGBQQO9VQ
zq6579PxxTf/RmCcYA7JMA/zyIGMvsRyIajAi9aVBbihJlPCKowhqhfd08BZbFc=
=KotH
-----END PGP SIGNATURE-----
Cédric Moreau
Dec 19, 2013, 9:48:29 AM12/19/13
to ope...@googlegroups.com
I am quite interested too in technical/theoretical tools extracting indicators from a WoT graph. Hope you guys have ideas on this, as it's clearly beyond my knowledge ..
--
Stéphane Laborde
Dec 19, 2013, 9:53:48 AM12/19/13
to ope...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 19/12/2013 15:48, C�dric Moreau a �crit :
Hash: SHA256
> I am quite interested too in technical/theoretical tools
> extracting indicators from a WoT graph. Hope you guys have ideas on
> this, as it's clearly beyond my knowledge ..
>
Cedric, as we just said it's not an OpenUDC goal, it's fully
> extracting indicators from a WoT graph. Hope you guys have ideas on
> this, as it's clearly beyond my knowledge ..
>
independant about this as well as the Linux Kernel relatively to which
softwares compose Debian, Archlinux, Fedora or whatever distribution.
If you are interested to improve OpenPGP tools, join an OpenPGP team
development like : http://openpgpjs.org/
As you can see OpenUDC is using OpenPGP, not developping it.
>
> 2013/12/19 Matthieu Vergne <matthie...@gmail.com
> <mailto:matthie...@gmail.com>>
>
>
> 2013/12/19 Arnaud Faisan <arnaud...@gmail.com
> <mailto:arnaud...@gmail.com>>
>
> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> identification system. I think such asystem could be usefuloutside
> OpenUDC scope. So, I think that partcould be a project on its own,
> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> identification system. I think such asystem could be usefuloutside
> what do you think ?
>
>
> I think it makes sense. But as you say it, it could be a project
> on its own, and so out of the scope of OpenUDC. Then it could
> deliver a library that OpenUDC could use if they want (otherwise
> they can use their own implementation, as they do now). If you
> intend to develop such a project, keep in touch with me {^_^}. I
> would like to make a TRM lib in Java, but if someone else would
> like to make one in C/C++, maybe it could be of interest for
> OpenUDC people. A discussion as started on the forum of Monnaie M
> to clarify the formalisation of the TRM :
> http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
>
> If you provide your own perspective, we could have a more
> comprehensive interpretation. I think this formalisation is a
> necessary step before to work on a given implementation.
>
> -- OpenUDC aims to provide a open standard for Universal Dividend
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> open...@muc.jappix.com <mailto:open...@muc.jappix.com>. --- You
>
>
> I think it makes sense. But as you say it, it could be a project
> on its own, and so out of the scope of OpenUDC. Then it could
> deliver a library that OpenUDC could use if they want (otherwise
> they can use their own implementation, as they do now). If you
> intend to develop such a project, keep in touch with me {^_^}. I
> would like to make a TRM lib in Java, but if someone else would
> like to make one in C/C++, maybe it could be of interest for
> OpenUDC people. A discussion as started on the forum of Monnaie M
> to clarify the formalisation of the TRM :
> http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
>
> If you provide your own perspective, we could have a more
> comprehensive interpretation. I think this formalisation is a
> necessary step before to work on a given implementation.
>
> -- OpenUDC aims to provide a open standard for Universal Dividend
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> received this message because you are subscribed to the Google
> Groups "OpenUDC" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> openudc+u...@googlegroups.com
> <mailto:openudc%2Bunsu...@googlegroups.com>. For more options,
> Groups "OpenUDC" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> openudc+u...@googlegroups.com
> visit https://groups.google.com/groups/opt_out.
>
>
> -- OpenUDC aims to provide a open standard for Universal Dividend
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> open...@muc.jappix.com. --- You received this message because you
> are subscribed to the Google Groups "OpenUDC" group. To unsubscribe
> from this group and stop receiving emails from it, send an email to
> openudc+u...@googlegroups.com. For more options, visit
> https://groups.google.com/groups/opt_out.
>
>
> -- OpenUDC aims to provide a open standard for Universal Dividend
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> open...@muc.jappix.com. --- You received this message because you
> are subscribed to the Google Groups "OpenUDC" group. To unsubscribe
> from this group and stop receiving emails from it, send an email to
> openudc+u...@googlegroups.com. For more options, visit
> https://groups.google.com/groups/opt_out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJSswh6AAoJELdo2ekCUDkjGCQIAK53Fn6bFA9enOQST/ZFC7lE
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
jfKYhTslLaAisRQ4upZs123iHIW1BH5GxRZP76jY09QOj6C55FCH68whrah4neWZ
T71qjaCXBI+GoCZjRiExrkXKHa3hHaZy79CkXgRXQ0dZAMdRGZB7TWAJlY5Yddt4
5CdYT/typc2yitwG09iJyb1jymLOEzMe6ALsFs+2dgrNGBM+dkYH5sBArdrClGAl
6RlBF+lOklrtLTx3mDCXujQHfeQIEP//9UuTHZ710RqY1D6AogdBs11jzvaEvQ0R
oPmSdapRy7zZzm+2GGLZ1i2AG9Va9X8wdQuLdNQ0Ns5YBq2pIaFFc3z2hIgWWos=
=/LYi
-----END PGP SIGNATURE-----
Cédric Moreau
Dec 19, 2013, 10:05:24 AM12/19/13
to ope...@googlegroups.com
Actually I'm not talking about OpenPGP specifically, just about graphs properties.
Shouldn't OpenUDC team be interested in WoT graphs ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Stéphane Laborde
Dec 19, 2013, 10:13:52 AM12/19/13
to ope...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 19/12/2013 16:05, C锟絛ric Moreau a 锟絚rit :
Hash: SHA256
> Actually I'm not talking about OpenPGP specifically, just about
> graphs properties. Shouldn't OpenUDC team be interested in WoT
> graphs ?
>
Users of OpenUDC will be interested in, for sure, you are right.
> graphs properties. Shouldn't OpenUDC team be interested in WoT
> graphs ?
>
But OpenUDC development doesn't need to be interested in this at all.
What offer OpenPGP is enough to developp OpenUDC tools.
>
> 2013/12/19 St锟絧hane Laborde <gal...@glibre.org
> <mailto:gal...@glibre.org>>
>
> Le 19/12/2013 15:48, C锟絛ric Moreau a 锟絚rit :
>> I am quite interested too in technical/theoretical tools
>> extracting indicators from a WoT graph. Hope you guys have ideas
>> on this, as it's clearly beyond my knowledge ..
>
>
> Cedric, as we just said it's not an OpenUDC goal, it's fully
> independant about this as well as the Linux Kernel relatively to
> which softwares compose Debian, Archlinux, Fedora or whatever
> distribution.
>
> If you are interested to improve OpenPGP tools, join an OpenPGP
> team development like : http://openpgpjs.org/
>
> As you can see OpenUDC is using OpenPGP, not developping it.
>
>
>> 2013/12/19 Matthieu Vergne <matthie...@gmail.com
> <mailto:matthie...@gmail.com>
>> <mailto:matthie...@gmail.com
>> extracting indicators from a WoT graph. Hope you guys have ideas
>> on this, as it's clearly beyond my knowledge ..
>
>
> Cedric, as we just said it's not an OpenUDC goal, it's fully
> independant about this as well as the Linux Kernel relatively to
> which softwares compose Debian, Archlinux, Fedora or whatever
> distribution.
>
> If you are interested to improve OpenPGP tools, join an OpenPGP
> team development like : http://openpgpjs.org/
>
> As you can see OpenUDC is using OpenPGP, not developping it.
>
>
>> 2013/12/19 Matthieu Vergne <matthie...@gmail.com
> <mailto:matthie...@gmail.com>
>> <mailto:matthie...@gmail.com>>>
>
>
>> 2013/12/19 Arnaud Faisan <arnaud...@gmail.com
> <mailto:arnaud...@gmail.com>
>> <mailto:arnaud...@gmail.com
>
>
>> 2013/12/19 Arnaud Faisan <arnaud...@gmail.com
> <mailto:arnaud...@gmail.com>
>> <mailto:arnaud...@gmail.com>>>
>
>> Divide and rule : I see the WoT part of OpenUDC as a
>> decentralized identification system. I think such asystem could
>> be usefuloutside OpenUDC scope. So, I think that partcould be a
>> project on its own, what do you think ?
>
>
>> I think it makes sense. But as you say it, it could be a project
>> on its own, and so out of the scope of OpenUDC. Then it could
>> deliver a library that OpenUDC could use if they want (otherwise
>> they can use their own implementation, as they do now). If you
>> intend to develop such a project, keep in touch with me {^_^}. I
>> would like to make a TRM lib in Java, but if someone else would
>> like to make one in C/C++, maybe it could be of interest for
>> OpenUDC people. A discussion as started on the forum of Monnaie
>> M to clarify the formalisation of the TRM :
>> http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
>
>> If you provide your own perspective, we could have a more
>> comprehensive interpretation. I think this formalisation is a
>> necessary step before to work on a given implementation.
>
>> -- OpenUDC aims to provide a open standard for Universal
>> Dividend Crypto-Currencies.
>
>> homepage: http://openudc.org --- git's home:
>> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
>> open...@muc.jappix.com <mailto:open...@muc.jappix.com>
> <mailto:open...@muc.jappix.com <mailto:open...@muc.jappix.com>>.
>
>> Divide and rule : I see the WoT part of OpenUDC as a
>> decentralized identification system. I think such asystem could
>> be usefuloutside OpenUDC scope. So, I think that partcould be a
>> project on its own, what do you think ?
>
>
>> I think it makes sense. But as you say it, it could be a project
>> on its own, and so out of the scope of OpenUDC. Then it could
>> deliver a library that OpenUDC could use if they want (otherwise
>> they can use their own implementation, as they do now). If you
>> intend to develop such a project, keep in touch with me {^_^}. I
>> would like to make a TRM lib in Java, but if someone else would
>> like to make one in C/C++, maybe it could be of interest for
>> OpenUDC people. A discussion as started on the forum of Monnaie
>> M to clarify the formalisation of the TRM :
>> http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
>
>> If you provide your own perspective, we could have a more
>> comprehensive interpretation. I think this formalisation is a
>> necessary step before to work on a given implementation.
>
>> -- OpenUDC aims to provide a open standard for Universal
>> Dividend Crypto-Currencies.
>
>> homepage: http://openudc.org --- git's home:
>> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
>> open...@muc.jappix.com <mailto:open...@muc.jappix.com>
> --- You
>> received this message because you are subscribed to the Google
>> Groups "OpenUDC" group. To unsubscribe from this group and stop
>> receiving emails from it, send an email to
>> openudc+u...@googlegroups.com
> <mailto:openudc%2Bunsu...@googlegroups.com>
>> <mailto:openudc%2Bunsu...@googlegroups.com
>> received this message because you are subscribed to the Google
>> Groups "OpenUDC" group. To unsubscribe from this group and stop
>> receiving emails from it, send an email to
>> openudc+u...@googlegroups.com
> <mailto:openudc%2Bunsu...@googlegroups.com>
> <mailto:openudc%252Buns...@googlegroups.com>>. For more
4thtknpiMufC+UISAoutNFKGzb52N4SgpoqLgysWoVaDWYncIbDZHEn3ju2TtA7n
5rq6i3+M3bEy6mQPzx8teMIhCh3uMqTah7ab6f/oddnjrZ1COh3D8Xxo+1HACegZ
b9I1e0KSbxIw7l2HG+wQ0VxKEKSwBg3a2ZeLT7LMTQdMzao7u1pAMAN0BXI2Xcwx
GprED9WlEQ5HIpY8eELq8+I3Qt3eh7vMyl2mIJWQ7T7HgAAON/VRaoo9uK5oqHlS
gy50/hXq5ZugZzJrRJorbOh+/bik08xd6p6tp04fZjY93+sdQN4z3OhKtxF1+HQ=
=JMVt
-----END PGP SIGNATURE-----
Arnaud Faisan
Dec 19, 2013, 11:02:41 AM12/19/13
to ope...@googlegroups.com
Exactly, it could be a library providing an API with features such as :
- get the list of all identified people
- is a particular person (identified by, let's say, an International Citizen Identifier) alive/dead?
- set/get some properties (first name, last name, contact info, ...) for a particular person
Stéphane Laborde
Dec 19, 2013, 11:07:45 AM12/19/13
to ope...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 19/12/2013 17:02, Arnaud Faisan a �crit :
Hash: SHA256
> Exactly, it could be a library providing an API with features such
> as :
>
> * get the list of all identified people * is a particular person
> as :
>
> (identified by, let's say, an International Citizen Identifier)
> alive/dead? * set/get some properties (first name, last name,
> contact info, ...) for a particular person
>
> The goal being to provide a simple interface (abstraction) even if
> the internal mechanic of the "Decentralized Identification System"
> is complex (OpenPGP). As a first impression, I think OpenPGP is a
> very good idea but I also notice that it was not intended to
> accomplish such a "Decentralized Identification System" so I would
> be personally happy to focus on that part of project, which, as
> written earlier, could be a project on its own.
>
It is. If you want to start something concerning the interface OpenPGP
>
> The goal being to provide a simple interface (abstraction) even if
> the internal mechanic of the "Decentralized Identification System"
> is complex (OpenPGP). As a first impression, I think OpenPGP is a
> very good idea but I also notice that it was not intended to
> accomplish such a "Decentralized Identification System" so I would
> be personally happy to focus on that part of project, which, as
> written earlier, could be a project on its own.
>
/ OpenUDC, you can study OpenUDC LUD.
And then you can think about GLUD = http://openpgpjs.org/ +
http://node1.openudc.org:11371/udid2/
>
> Le jeudi 19 d�cembre 2013 15:02:22 UTC+1, Matthieu Vergne a �crit
> :
>
>
> 2013/12/19 Arnaud Faisan <arnaud...@gmail.com <javascript:>>
>
> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> identification system. I think such asystem could be usefuloutside
> OpenUDC scope. So, I think that partcould be a project on its own,
> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> identification system. I think such asystem could be usefuloutside
> what do you think ?
>
>
> I think it makes sense. But as you say it, it could be a project
> on its own, and so out of the scope of OpenUDC. Then it could
> deliver a library that OpenUDC could use if they want (otherwise
> they can use their own implementation, as they do now). If you
> intend to develop such a project, keep in touch with me {^_^}. I
> would like to make a TRM lib in Java, but if someone else would
> like to make one in C/C++, maybe it could be of interest for
> OpenUDC people. A discussion as started on the forum of Monnaie M
> to clarify the formalisation of the TRM :
> http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
> <http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460>
>
> If you provide your own perspective, we could have a more
> comprehensive interpretation. I think this formalisation is a
> necessary step before to work on a given implementation.
>
>
>
> I think it makes sense. But as you say it, it could be a project
> on its own, and so out of the scope of OpenUDC. Then it could
> deliver a library that OpenUDC could use if they want (otherwise
> they can use their own implementation, as they do now). If you
> intend to develop such a project, keep in touch with me {^_^}. I
> would like to make a TRM lib in Java, but if someone else would
> like to make one in C/C++, maybe it could be of interest for
> OpenUDC people. A discussion as started on the forum of Monnaie M
> to clarify the formalisation of the TRM :
> http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
> <http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460>
>
> If you provide your own perspective, we could have a more
> comprehensive interpretation. I think this formalisation is a
> necessary step before to work on a given implementation.
>
> -- OpenUDC aims to provide a open standard for Universal Dividend
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> open...@muc.jappix.com. --- You received this message because you
> are subscribed to the Google Groups "OpenUDC" group. To unsubscribe
> from this group and stop receiving emails from it, send an email to
> openudc+u...@googlegroups.com. For more options, visit
> https://groups.google.com/groups/opt_out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJSsxnPAAoJELdo2ekCUDkjNBIIAI1U4oruTzJ+slP3cIOqw4ji
> Crypto-Currencies.
>
> homepage: http://openudc.org --- git's home:
> https://github.com/Open-UDC/open-udc.git --- Multi User Chat:
> open...@muc.jappix.com. --- You received this message because you
> are subscribed to the Google Groups "OpenUDC" group. To unsubscribe
> from this group and stop receiving emails from it, send an email to
> openudc+u...@googlegroups.com. For more options, visit
> https://groups.google.com/groups/opt_out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
Jc2PrAaMPvLt4GC35IKFoWoq/Y9qZaSmPYmv+R4PlULsnfsa8XJBwfzWXNPTQKX+
9Ygdld5bAec+Ci5yGE78pkBKYrK8SJUOSQlGv3PWyLOtKU8I+/75tT+K8BOSsTsT
pDnL0HlT8yktWDAobRodI1vU2YwbfymEs21cSveiXfXWwVFpdt+CIQ8eylDMTsYJ
KjH4OINP6g0z6Xd6LpWxRQHiUi1a4vY5EOvI5Ls4QJx8bNg/W1s5wPVFoi9tRqiy
FuJMk5xPbcwobtIOyuYqGCGD2GvUFEm2VsCy5FnFMh+LxuHfB+lLIK/nTRd8Y9M=
=VctF
-----END PGP SIGNATURE-----
Arnaud Faisan
Dec 19, 2013, 12:20:06 PM12/19/13
to ope...@googlegroups.com
Yes, I would like to study the specification of LUD but I cannot find the RFC written by Jbar (that were available in a previous version of openudc.org website). Where are they now?
Concerning the UDID2 : for the same reason that putting semantic data in a primary key of a relational database is to avoid, I think it must also be avoided in the UDID2 or in my previous "International Citizen Identifier". People can make typo, people's name can change, some people don't know their birth date, ... If the goal of the UDID2 is to be immutable, then there is something wrong using semantic data into it.
An identifier should not make sense by itself, what make sense is the data and the data should be linked to that identifier, making possible further modifications of the data without breaking the identifier.
Le jeudi 19 décembre 2013 17:07:45 UTC+1, MrGaluel a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 19/12/2013 17:02, Arnaud Faisan a �crit :
> Exactly, it could be a library providing an API with features such
> as :
>
> * get the list of all identified people * is a particular person
> (identified by, let's say, an International Citizen Identifier)
> alive/dead? * set/get some properties (first name, last name,
> contact info, ...) for a particular person
>
> The goal being to provide a simple interface (abstraction) even if
> the internal mechanic of the "Decentralized Identification System"
> is complex (OpenPGP). As a first impression, I think OpenPGP is a
> very good idea but I also notice that it was not intended to
> accomplish such a "Decentralized Identification System" so I would
> be personally happy to focus on that part of project, which, as
> written earlier, could be a project on its own.
>
It is. If you want to start something concerning the interface OpenPGP
/ OpenUDC, you can study OpenUDC LUD.
And then you can think about GLUD = http://openpgpjs.org/ +
http://node1.openudc.org:11371/udid2/
>
> Le jeudi 19 d�cembre 2013 15:02:22 UTC+1, Matthieu Vergne a �crit
jbar
Dec 19, 2013, 12:21:36 PM12/19/13
to ope...@googlegroups.com, arnaud...@gmail.com
Sure it can be a project on its own, but it doesn't exist before
OpenUDC and should so be OpenUDC-compatible (or vice-versa) ;-).
I suppose you have read such draft ?! :
https://github.com/Open-UDC/open-udc/blob/master/docs/OpenUDC_Authentication_Mechanisms.draft.txt
(which is still, really a draft :-p )
On Thu, 19 Dec 2013 08:02:41 -0800 (PST)
Arnaud Faisan <arnaud...@gmail.com> wrote:
> Exactly, it could be a library providing an API with features such as :
>
> - is a particular person (identified by, let's say, an International
> Citizen Identifier) alive/dead?
> - set/get some properties (first name, last name, contact info, ...) for
> a particular person
>
> The goal being to provide a simple interface (abstraction) even if the
> internal mechanic of the "Decentralized Identification System" is complex
> (OpenPGP). As a first impression, I think OpenPGP is a very good idea but I
> also notice that it was not intended to accomplish such a "Decentralized
> Identification System" so I would be personally happy to focus on that part
> of project, which, as written earlier, could be a project on its own.
>
>
> Le jeudi 19 décembre 2013 15:02:22 UTC+1, Matthieu Vergne a écrit :
> >
> >
> > 2013/12/19 Arnaud Faisan <arnaud...@gmail.com <javascript:>>
>
> The goal being to provide a simple interface (abstraction) even if the
> internal mechanic of the "Decentralized Identification System" is complex
> (OpenPGP). As a first impression, I think OpenPGP is a very good idea but I
> also notice that it was not intended to accomplish such a "Decentralized
> Identification System" so I would be personally happy to focus on that part
> of project, which, as written earlier, could be a project on its own.
>
>
> Le jeudi 19 décembre 2013 15:02:22 UTC+1, Matthieu Vergne a écrit :
> >
> >
> >
> >> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> >> identification system. I think such a system could be useful outside
> >> OpenUDC scope. So, I think that part could be a project on its own, what
> >> do you think ?
> >>
> >
> > I think it makes sense. But as you say it, it could be a project on its
> > own, and so out of the scope of OpenUDC. Then it could deliver a library
> > that OpenUDC could use if they want (otherwise they can use their own
> > implementation, as they do now). If you intend to develop such a project,
> > keep in touch with me {^_^}. I would like to make a TRM lib in Java, but if
> > someone else would like to make one in C/C++, maybe it could be of interest
> > for OpenUDC people. A discussion as started on the forum of Monnaie M to
> > clarify the formalisation of the TRM :
> > http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
> >
> > If you provide your own perspective, we could have a more comprehensive
> > interpretation. I think this formalisation is a necessary step before to
> > work on a given implementation.
> >
>
> >> Divide and rule : I see the WoT part of OpenUDC as a decentralized
> >> identification system. I think such a system could be useful outside
> >> OpenUDC scope. So, I think that part could be a project on its own, what
> >> do you think ?
> >>
> >
> > I think it makes sense. But as you say it, it could be a project on its
> > own, and so out of the scope of OpenUDC. Then it could deliver a library
> > that OpenUDC could use if they want (otherwise they can use their own
> > implementation, as they do now). If you intend to develop such a project,
> > keep in touch with me {^_^}. I would like to make a TRM lib in Java, but if
> > someone else would like to make one in C/C++, maybe it could be of interest
> > for OpenUDC people. A discussion as started on the forum of Monnaie M to
> > clarify the formalisation of the TRM :
> > http://merome.net/monnaiem/phpBB3/viewtopic.php?f=3&t=61&p=460
> >
> > If you provide your own perspective, we could have a more comprehensive
> > interpretation. I think this formalisation is a necessary step before to
> > work on a given implementation.
> >
>
Arnaud Faisan
Dec 19, 2013, 12:33:48 PM12/19/13
to ope...@googlegroups.com, arnaud...@gmail.com
Surely, it must be OpenUDC-compatible, that is the goal. I will open a dedicated thread to talk about it.
Thanks for the link, this is the document I was referring.
jbar
Dec 19, 2013, 3:45:54 PM12/19/13
to ope...@googlegroups.com, arnaud...@gmail.com
On Thu, 19 Dec 2013 09:20:06 -0800 (PST)
Arnaud Faisan <arnaud...@gmail.com> wrote:
> Yes, I would like to study the specification of LUD but I cannot find the
> RFC written by Jbar (that were available in a previous version of
> openudc.org website). Where are they now?
>
> Concerning the UDID2 : for the same reason that putting semantic data in a
> primary key of a relational database is to avoid, I think it must also be
> avoided in the UDID2 or in my previous "International Citizen Identifier".
> People can make typo, people's name can change, some people don't know
> their birth date, ... If the goal of the UDID2 is to be immutable, then
> there is something wrong using semantic data into it.
>
which don't know their birth date, there are less and less civil
registration which may assign them a different birth date.
Concerning the name and forename, the spec say clearly that that is are
the one given at birth, not any changed one.
Also if people have only one name, it is possible to put only a "-"
char in the forename field.
If you try to assign a unique identifier like the french social
security number, it will need an unique authority and then u can't avoid
centralization.
On the other hand is possible to put bio-metric data (like
fingerprint) inside an OpenPGP certificate, to help building a
decentralized unique "identifier". But it require a standardized (and
"patent-free") open format, democratization of fingerprint scanners,
and will still require to be coupled with some data (like birth date)
because some very different people may have the same fingerprint
(number of duplicate fingerprint for different people may depend on the
resolution/format used).
About fingerprint i don't even talk about some psychological resistance
it may encounter also.
Arnaud Faisan
Dec 19, 2013, 6:34:44 PM12/19/13
to jbar, ope...@googlegroups.com
On 19 December 2013 21:45, jbar <jeanjacqu...@gmail.com> wrote:
>
>
>
> On Thu, 19 Dec 2013 09:20:06 -0800 (PST)
> Arnaud Faisan <arnaud...@gmail.com> wrote:
>
> > Yes, I would like to study the specification of LUD but I cannot find the
> > RFC written by Jbar (that were available in a previous version of
> > openudc.org website). Where are they now?
> >
> > Concerning the UDID2 : for the same reason that putting semantic data in a
> > primary key of a relational database is to avoid, I think it must also be
> > avoided in the UDID2 or in my previous "International Citizen Identifier".
> > People can make typo, people's name can change, some people don't know
> > their birth date, ... If the goal of the UDID2 is to be immutable, then
> > there is something wrong using semantic data into it.
> >
>
> OpenUDC is planned for the future, and today even there are still people
> which don't know their birth date, there are less and less civil
> registration which may assign them a different birth date.
I know the change of some data only happen in very rare situations but still, it happens. Is there a specific reason for which the semantic data is included directly in the UDID2 or was it just a convenient way to link the semantic data with the OpenPGP certificate?
>
> Concerning the name and forename, the spec say clearly that that is are
> the one given at birth, not any changed one.
Sorry, I did not read it properly. If the goal is to identify a person, what would be the point of having an old name, that is no longer used, in order to perform this identification?
>
> Also if people have only one name, it is possible to put only a "-"
> char in the forename field.
>
> If you try to assign a unique identifier like the french social
> security number, it will need an unique authority and then u can't avoid
> centralization.
I don't want to assign a unique identifier like the french social security number because it contains semantic data.
>
> On the other hand is possible to put bio-metric data (like
> fingerprint) inside an OpenPGP certificate, to help building a
> decentralized unique "identifier". But it require a standardized (and
> "patent-free") open format, democratization of fingerprint scanners,
> and will still require to be coupled with some data (like birth date)
> because some very different people may have the same fingerprint
> (number of duplicate fingerprint for different people may depend on the
> resolution/format used).
>
> About fingerprint i don't even talk about some psychological resistance
> it may encounter also.
Let's talk about it. I personally would not be so keen about publishing my biometric data on public servers but some other people might. Let's take another example, I am willing to publish my real first and last names in order for people to identify me because there are the names that I use in real life. But some other people might not because they use their nickname in real life.
--
Arnaud Faisan
After all, one size does not fit all. If people consider that a nickname is enough to identify their friend, why not. And it does not have to be like this all the time, maybe the official name could be added later?
What is an official name by the way? It is the name that is written on your official papers provided by a centralized authority in the scope of a centralized identification system. So, if OpenUDC requires to include or link official names to UDID2, then it indirectly relies on a centralized identification system, which I think, is what we try to avoid!
--
Arnaud Faisan
Reply all
Reply to author
Forward
0 new messages