Potential starting points for collaboration

[els]

Until there is a collaboration site, I'll post my collaboration ideas
here. I am still not totally in agreement with using "openmoney",
because people googling that word would likely become confused as to
which site to visit, especially once we start posting our own ideas on
the web.

It might help if we start by looking at very simple "reports", see:

http://twollars.com/alanrosenblith (view html source code)
http://tyaga.org/prowl/reports/cc_report.txt

My viewpoint:

- To me, it is easier to parse the cc_report.txt, but I need to hear
from others whether the microformats in twollars will be easier for
others to generate parser code for.

- If we want to give people the ability to use existing blogs that do
not convert user-entered transaction records into a microformatted
structure, then I am leaning towards keeping a Prowl-style, no mark-up
published 'representation' as default.

- For web apps that do have capability to generate microformatted
transaction records, then we should give them that option.

- Do we want stripped-marked-down version of a transaction record to
have the same meaning as the microformatted version, or do we decide
to avoid coordinating that between the two types of representations?

I say let us coordinate to have the two representations match up. Any
comments?

[Guillaume P. Lebleu]

Edgar,

I started a wiki page on my personal server for now until I've set up
the wiki on the final server.
I'm following the http://microformats.org process.

http://lebleu.org/wiki/index.php/Transaction_Record_Examples

To answer your questions: we can have multiple representations
although the POSH one is the most reader-friendly. The only important
thing is for these representations to be coordinated.

Guillaume

[Edgar Sioson]

Could you show me example parser code for the Twollars format?

[Miles Thompson]

haven't done this before so I'm sure this could be improved but had a play with this - to see how hard.

some comments relating to ease of coding in-line with the JavaScript.

Just in case the attachment doesn't come through I'm going to also post the JavaScript below.

Basically this parses through the "POSH" html at http://twollars.com/alanrosenblith
and works out the total postitive/negative balance (just as an example).

Of course its javascript/jquery based. One would of course want to use appropriate parsing library depending on server/client context.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js" type="text/javascript"></script>
  <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">
$(document).ready(function() {
 var posBalance=0;
 var negBalance=0;
 
 // foreach record, basically.
 jQuery('.rec').each(function() {      //NB ".rec" seems like a stupid name for the root element identifier - hcard for example uses ".hcard"
  
    var record = jQuery(this);

    record.find('.recv').each(function() {
         var tmp = jQuery(this); 
         if (tmp.text()=='RECEIVED') {
            // ignore NB.. wtf? why are we labeling the 'text' and the 'number' with the same class ?
         }
         else {
            posBalance = posBalance + parseInt(tmp.text()); // drops the "tw" since we don't care about currency
         }
    });

   record.find('.gave').each(function() {
         var tmp = jQuery(this);   
         if (tmp.text()=='GAVE') {
            // ignore NB.. wtf? why are we labeling the 'text' and the 'number' with the same class ?
         }
         else {                    
            negBalance = negBalance + parseInt(tmp.text()); // drops the "tw" since we don't care about currency
         }
    });
   
 });
 
  $("div#result").html("<p>positive balance:" + posBalance + "</p><p> negative balance:" + negBalance +"</p>");
});
</script>

[Edgar Sioson]

Okay, the code does not look too complicated. Jquery does a lot - I need to be more familiar with that framework.
 
However, just to be honest and without discouraging collaboration, my gut feeling is that promoting wider adoption would mean default support for "publisher" platforms that may give respond to something as simple as "ftp :// mystore.org/acct101.txt". In that case, the records are unlikely to be microformatted. But I'll try to keep an open mind.
 
Ok, its getting late here - I'll check again tomorrow.
 
Edgar
 

---

Date: Thu, 26 Mar 2009 16:53:05 +1300

Subject: Re: Potential starting points for collaboration

From: utu...@gmail.com
To: prowl...@googlegroups.com

GAVE to @emilysquest 10tw
Give 10 Twollars @emilysquest for helping me move about 2 hours ago

GAVE to @cryku 10tw
Give 10 Twollars @cryku for helping me move about 2 hours ago

GAVE to @katin 10tw
give 10 tw @katin for adding "share" button and screening map to http://www.themoneyfix.org about 5 days ago

GAVE to @hannah_lewis 3tw
give 3 twollars @hannah_lewis for the tweet about the Local Capital Summit: http://bit.ly/158Lco about 6 days ago

GAVE to @xtof_fr 5tw
give 5 Twollars @xtof_fr for blog translation about 8 days ago

RECEIVED from @eisokant 2tw
RT 2 Twollars @AlanRosenblith: great conversation with @eisokant this morning. Multi-currency Twollars is almost a go. Great work guys! about 9 days ago

RECEIVED from @neuesgeld 1tw
Give 1 Twollars @AlanRosenblith for his work on new currencies - and his blog entry on Twollars http://tinyurl.com/alan-on-twollars about 12 days ago

GAVE to @biohabit 5tw
give 5 Twollars @biohabit for ongoing great work in the community about 14 days ago

RECEIVED from @eisokant 10tw
RT 10 Twollars @AlanRosenblith: My blog post on Twollars: http://bit.ly/X79L -- (Wow, Thank you Alan for the kind words!) about 14 days ago

RECEIVED from @mtirel 4tw
give 4 twollars @AlanRosenblith for the metacurrency project http://metacurrency.geekgene.com/ Waouh ! about 14 days ago

res

---

Express your personality in color! Preview and select themes for Hotmail®. See how.

[Miles Thompson]

On Thu, Mar 26, 2009 at 5:29 PM, Edgar Sioson <sios...@hotmail.com> wrote:
>
> Okay, the code does not look too complicated. Jquery does a lot - I need to be more familiar with that framework.
>
> However, just to be honest and without discouraging collaboration, my gut feeling is that promoting wider adoption would mean default support for "publisher" platforms that may give respond to something as simple as "ftp :// mystore.org/acct101.txt". In that case, the records are unlikely to be microformatted. But I'll try to keep an open mind.
>
> Ok, its getting late here - I'll check again tomorrow.
>

Hope you had a good sleep,

A quick response on subject of formats versus standardization.

One thing to bear in mind is that the actual serialization format used
is not nearly as important as the semantic structure that can be
supported. Quite hard thing to get your head around anything without a
specific format to use as an example, but in theory one  'abstract'
format can be supported in multiple 'serialization' formats, all
transformable into one another.

Just purely for example TopicMaps as an ISO standard is actually
defined as an abstract standard that can realized in multiple
different ways.

Here are some example bits of a TopicMap syntax in different
serialization formats (there of them, there are a few more, including
even a graphical one).

CTM:

wadlow - "Robert Wadlow";
date-of-birth: 1918-02-22;
height: 2.72 .

LTM:

[cxtm : syntax = "CXTM"]
{cxtm, specification, "http://www.isotopicmaps.org/cxtm/cxtm.html"}
published-by(cxtm : publication, iso : publisher)

XTM

<topic id="t1">
<baseName><baseNameString>New York</baseNameString></baseName>
</topic>

<topic id="b298">
<baseName><baseNameString>Brooklyn Bridge</baseNameString>
</baseName></topic>

<association>
<member>
<roleSpec><topicRef xlink:href="#when-in"/></roleSpec>
<topicRef xlink:href="#t1"/></member>
<member>
<roleSpec><topicRef xlink:href="#visit"/></roleSpec>
<topicRef xlink:href="#b298"/></member>
</association>

I couldn't be bothered constructing examples that actually represent
the same exact information in these different formats but hopefully
you get the idea that I could have, in theory.

All of which is just another way of saying that once we settle on, say
a format defined as "POSH" or some other format we can always create
"plain text" serialization for it (or vice-versa).

In the early days, of course, you do need to stick to one format just
to keep things practical and simple, but in theory one can turn this
into a range of representations down the line.

One option we may want to consider is defining it as an RDF OWL syntax
or something to start with and showing how this can be serialized into
a "POSH" representation for Microformat purposes or plain text or JSON
format for other purposes.

Or something.

Just thinking out loud really. Hope this was helpful

Miles

PS
Yeah jQuery really is quite neat, as I am discovering myself recently.

[Guillaume P. Lebleu]

On Mar 25, 2009, at 10:07 PM, Miles Thompson wrote:

> One thing to bear in mind is that the actual serialization format used
> is not nearly as important as the semantic structure that can be
> supported.

I agree. One semantic structure, multiple serial representations. Re:
the use of RDF OWL, I think we can document the semantic structure in
plain English for now, since we are dealing with fairly simple
structures.

Guillaume

[Edgar Sioson]

Ok, you explained well and I have the same ideas about different representations of the same "information pattern". But perhaps I have not been good at explaining the roots of the concerns that led to Prowl's design strategy. 
 
First, I think for the "openmoney" spec, the focus should be on enabling highly auditable "accounting/publisher/reporter" systems. This does not necessarily mean that transaction data and history needs to be publicly viewable; it mostly implies that different "auditor" services would be able to agree on the validity of ledger data.
 
I think we could look at transaction record representations at three different stages:
 
1) Device-to-Accounting System record representation: One of possibly many record representations that allows a buyer and seller to complete a transaction. The "om" specs should NOT cover this. This is mostly user interface preferences such as web forms, email, SMS for submitting transaction data to and getting authorization from any involved Accounting Systems (such as for sufficient funds, user ID, etc.). Most cc systems to-date required transactors to use the same Accounting System -- but I hope we agree that this restriction should be avoided in the design of the "om" specs. For example, right now Twollars enforces this restriction.

 
2) Accounting-To-Publication record representation: One or more representations that should be KEY considerations in the "om" specs - please comment whether you agree or not. I compared this to a journal entry in the Prowl specs. Any "Notary" service should be able to easily ascertain that the seller and buyer agreed to complete a transaction, regardless of whether the buyer and seller belong to the same or different Accounting Sytems.
 
Say Edgar does not have a Twitter account but has tyaga.org. He sells Guillaume a book, but does not want to have to set up a Twitter account just to receive a payment from Guillaume. Also, Guillaume wants the flexibility to decide whether to use his Tweeter account or his lebleu.org site to "publish" a payment.
 
Suppose Guillaume tweets "GIVE to tyaga.org 10.00 bucks." with no additional mark-ups.
Edgar uses the tyaga.org site to publish "RECEIVE from @glebleu 10.00 bucks.", with the @glebleu marked up and anchored to twitter.org/glebleu.
 
A Notary service should understand that in order to cross-verify the validity of this particular transaction record, matching GIVE/RECIEVE representations should be 'pulled' from tyaga.org and twitter.com/glebleu. However, each of the above representations **omits** the other party from the published record, so a Notary service would need additional information about how the record was submitted. Is there an implicit assumption that transaction records would have to be submitted through RSS or Atom feeds, and if so, do we really want to even assume that capability?
 
Prowl's approach was to simplify cross-verification by requiring both sites to publish the same record using a basic but complete representation:
 
2009-03-26 from twitter.com/glebleu to tyaga.org 10.00 bucks #some_id.
 
Notice that the above representation may be submitted by anyone from anywhere - it does not require transaction records to be submitted as Atom feeds - and a Notary would still know where to verify that copies of the same record have been published. (Not that efficiency should matter this early in the discussion, but in Prowl's case, a record_string-in-a-page verification approach would do, no need to parse for tags, possibly encouraging novice coders to contribute.)
 
Notice also that Prowl's representation does not require a 'publisher' platform to add microformats, which enables the use of any existing blog platform and even allows for the possibility of uploading a text file to publish a transaction record. This is what I meant by widespread adoption - thinking more of "publisher" support which may include very simple web sites with limited scripting support. On the other hand, I agree that aggregators or "reporters" should be expected to have the ability to generate different representations of transaction data history, what I call "reports" in Prowl. 
 

3) Publication-to-"Reporting or Posting": This part aggregates Notarized records within reporting periods for reconciliation, auditability and evaluation purposes. I am very open to supporting different types of representations, including adding meta tags, structural tags and microformats to posted records. But first we need to really discuss #2 some more.

Sorry for the long post - just trying to emphasize the need to discuss Notary service and not just the aggregation service.
 
Edgar
 

> Date: Thu, 26 Mar 2009 18:07:22 +1300

> Subject: Re: Potential starting points for collaboration
> From: utu...@gmail.com
> To: prowl...@googlegroups.com
>
>

[els]

Just to summarize the previous post - let me know if you think I'm
assuming too much:

"om" spec should support the principle of a "dumb but with an
excellent memory" Notary service.

All that a Notary is expected to do is to keep a copy of any
transaction record that has been cross-verified to have been published
in the originator and recipient domains.

We should not expect Notaries to predict or accomodate numerous
published representations of the same transaction record. Remember,
this applies only to a published transaction record that has to be
witnessed - there would and should be more flexibility in the allowed
representations of aggregated records or reports.

In other words, let us try to keep the "witnessing" requirement easy
to fulfill in order to promote the scalability of inter-domain trades.

Edgar

On Mar 26, 11:32 am, Edgar Sioson <sioso...@hotmail.com> wrote:
> Ok, you explained well and I have the same ideas about different representations of the same "information pattern". But perhaps I have not been good at explaining the roots of the concerns that led to Prowl's design strategy.
>
> First, I think for the "openmoney" spec, the focus should be on enabling highly auditable "accounting/publisher/reporter" systems. This does not necessarily mean that transaction data and history needs to be publicly viewable; it mostly implies that different "auditor" services would be able to agree on the validity of ledger data.
>
> I think we could look at transaction record representations at three different stages:
>
> 1) Device-to-Accounting System record representation: One of possibly many record representations that allows a buyer and seller to complete a transaction. The "om" specs should NOT cover this. This is mostly user interface preferences such as web forms, email, SMS for submitting transaction data to and getting authorization from any involved Accounting Systems (such as for sufficient funds, user ID, etc.). Most cc systems to-date required transactors to use the same Accounting System -- but I hope we agree that this restriction should be avoided in the design of the "om" specs. For example, right now Twollars enforces this restriction.
>
> 2) Accounting-To-Publication record representation: One or more representations that should be KEY considerations in the "om" specs - please comment whether you agree or not. I compared this to a journal entry in the Prowl specs. Any "Notary" service should be able to easily ascertain that the seller and buyer agreed to complete a transaction, regardless of whether the buyer and seller belong to the same or different Accounting Sytems.
>
> Say Edgar does not have a Twitter account but has tyaga.org. He sells Guillaume a book, but does not want to have to set up a Twitter account just to receive a payment from Guillaume. Also, Guillaume wants the flexibility to decide whether to use his Tweeter account or his lebleu.org site to "publish" a payment.
>
> Suppose Guillaume tweets "GIVE to tyaga.org 10.00 bucks." with no additional mark-ups.
> Edgar uses the tyaga.org site to publish "RECEIVE from @glebleu 10.00 bucks.", with the @glebleu marked up and anchored to twitter.org/glebleu.
>
> A Notary service should understand that in order to cross-verify the validity of this particular transaction record, matching GIVE/RECIEVE representations should be 'pulled' from tyaga.org and twitter.com/glebleu. However, each of the above representations **omits** the other party from the published record, so a Notary service would need additional information about how the record was submitted. Is there an implicit assumption that transaction records would have to be submitted through RSS or Atom feeds, and if so, do we really want to even assume that capability?
>
> Prowl's approach was to simplify cross-verification by requiring both sites to publish the same record using a basic but complete representation:
>
> 2009-03-26 from twitter.com/glebleu to tyaga.org 10.00 bucks #some_id.
>
> Notice that the above representation may be submitted by anyone from anywhere - it does not require transaction records to be submitted as Atom feeds - and a Notary would still know where to verify that copies of the same record have been published. (Not that efficiency should matter this early in the discussion, but in Prowl's case, a record_string-in-a-page verification approach would do, no need to parse for tags, possibly encouraging novice coders to contribute.)
>
> Notice also that Prowl's representation does not require a 'publisher' platform to add microformats, which enables the use of any existing blog platform and even allows for the possibility of uploading a text file to publish a transaction record. This is what I meant by widespread adoption - thinking more of "publisher" support which may include very simple web sites with limited scripting support. On the other hand, I agree that aggregators or "reporters" should be expected to have the ability to generate different representations of transaction data history, what I call "reports" in Prowl.  
>
> 3) Publication-to-"Reporting or Posting": This part aggregates Notarized records within reporting periods for reconciliation, auditability and evaluation purposes. I am very open to supporting different types of representations, including adding meta tags, structural tags and microformats to posted records. But first we need to really discuss #2 some more.
>
> Sorry for the long post - just trying to emphasize the need to discuss Notary service and not just the aggregation service.
>
> Edgar
>
>
>
>
>
> > Date: Thu, 26 Mar 2009 18:07:22 +1300
> > Subject: Re: Potential starting points for collaboration
> > From: utu...@gmail.com
> > To: prowl...@googlegroups.com
>

> _________________________________________________________________
> Quick access to Windows Live and your favorite MSN content with Internet Explorer 8.http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=...- Hide quoted text -
>
> - Show quoted text -

[Guillaume P. Lebleu]

I agree with your summary.

I have a strong preference for POSH/microformatted content for
information that is supposed to be machine-readable.

My rationale is that:
- it is the representation that is the easiest for Web developers to
add support for in their existing Web app.
- it is the most user-friendly machine-readable representation as it
can be styled very nicely with CSS
- I do not expect users to have to learn the POSH/microformat syntax.
It will be generated from a dedicated form or simplified Twollars-like
syntax.

Guillaume

[Miles Thompson]

Edgar,

First off let me mention that I found this http://tyaga.org/prowl/obs_sequence.php  and this http://tyaga.org/prowl/prowl_doc.php to be heplful for anyone that may have missed them.

I hope I don't screw this up but I'm going to mirror some of your comments back to you before I reply on each one, please do let me know if I misunderstood.

I think you said..

1. It would be good if the format had both ends of any transaction clearly stated in the record
2. It would be good if the format was such that the transaction record was basically identical, no matter where hosted

Both of these things sound like worth doing to me. As you say, it will make processing and checking of records a whole bunch easier and I think that's a worthy goal in itself. I guess that both of these points are format specific but lets just say that it makes sense that the canonical format should have this feature. That way harvesters could just charge around the net and harvest records as pure text, dump them somewhere else, and process later (amongst other advantages).

--
I think you said
3. We should distinguish between three stages
      - 1 - information whilst it is being transmitted from end users to their 'accounting system' or currency provider
      - 2 - information being published by currency providers/accounting systems (presumably for open auditing purposes)
      - 3 - aggregated data (tallies and such) that might be the result of such auditing procedures

4. Furthermore that the focus of our attention should be on creating a standard for 2 rather than the former or latter.

Well, OK yes, this sounds reasonable, certainly at first this is the kind of use case I think such a standard would be built for.

However whilst I agree it makes sense to concentrate on this as the first thing to handle (and yes the part I'd be most interested in getting right) I don't think that precludes, for example the format defined for 2 being used for the 1 use case, or at least something similar. Clearly that would be up to individual implementers to decide.

At this early stage I would feel uncomfortable completely excluding the 1st use case from this proto-standard we are working on but yes OK I do agree that it makes sense, to concentrate on the second situation as the focus at least at first.

--

This raises a question are we talking about creating a standard here? Gulliame you said that you are following the 'microformat process' Do you mean per the discussion here: http://microformats.org/wiki/process  that sounds great to me. I'd be keen that we should do that if only to get a better consistency of what exactly we are doing. ISO or W3C would be waaaaaaayyy too hard for what we want to do right now.

Edgar since PROWL is all about publishing stuff on web sites/blogs it does seem to me that POSH is a fairly good fit for what you want to do with Prowl, but then again I might be wrong. Don't want to get into a religious discussion about formats per se.

Edgar have a read of the pricinciples.. do they look attractive to you?
http://microformats.org/wiki/principles

We should also wonder to what extent we are doing would (even potentially) overlap with rel-payment
http://microformats.org/wiki/rel-payment

I dont think so - if anything just because rel-payment is about facilitating something like the 1 use case rather than 2.

--

Couple more things...

--

Maybe a glossary of key terms is something we should do if only for discussion amongst ourselves. My feeling is that we should err on the side of easily understood-at-first-though-sometimes-not-strictly-accurate terminology rather than generic-and-therefore-accurate-but-hard-to-follow words like 'parameter'.

--
My eyebrows were raised a little at the mention of "#some_id" because of course that is going to be "hard" to synchronize at both ends of a transaction. "hard" is something of an understatement.  From your other discussions on the net it appears this is more about binding together two related transactions together which makes sense. Some system where by unique ids (in a given name space) can be proposed on one end and then accepted on the other end might work, but of course it is complicated so probably deserves some more discussion.

--
A related issue is how we are suggesting to establish identity of accounting 'end points'. URL like subject identifiers (with, possibly an ability to 'alias' short names to these longer ids) sound like a good way to do that, but its a tricky question of course, especially when things like 'shared accounts' and such might come up. Or is it?

--
If we did create a microformat what would it be called?

--
Personally I'm very interested in the 'extending a line of credit' side of things that is per the kind of thing that Ripple pay does. Another way to look at that is to note that everytime someone 'joins' twollars (and when exactly do they do that?) the total number of twollars in existence goes up  by another 50.

We can all see a thousand deficiencies with twollars as a currency system, but that is one - the potential or real devaluation of all twollars by the fact that anyone can join twitter (or join Twollars) and create 50 more of them. I think this is also a very important consideration when trying to evalute the relative health or unhealth of a currency issuing authority eg a local exchange trading system - that is how many of their 'dollars' are in existence or in potential existence at that time.

Of course the difference between 'actual' twollars (as given or spent) and  'potential' twollars - as created at the time of extending a line of credit - is an important and tricky question of semantics.

But rather than being a question of semantics I'd liek to see, at least at some point down the line any such standard as this able to be extended to include 'publication' of 'credit limits' or 'line sof credit' or 'potential curency' in existence at that time.

Am I way off base?

--

Wish you all the best. Sorry that I must shoot through now and pick up my kids from school

Look forward to checking in again in coming days.

THanks

Miles
http://milo.graytime.org

[Utunga]

My apologies if people received a half-completed copy of the below
message. I had a bit of a 'usability problem' with my mouse which is
one of those that has buttons on the side so that just going to pick
it up (apparently) can sometimes result in sending incomplete emails.
Sorry about that.

miles

On Apr 1, 1:48 pm, Miles Thompson <utu...@gmail.com> wrote:
> Edgar,
>

> First off let me mention that I found this http://tyaga.org/prowl/obs_sequence.php and thishttp://tyaga.org/prowl/prowl_doc.phpto be heplful for anyone that may have
> missed them.

[Edgar Sioson]

I apologize for not being able to reply quickly. I have been on the road and Internet connectivity was expensive. I'll reread thru the comments and respond by tomorrow night Seattle time.

So far, I feel that we are at least on our way to finding a good, common starting point for this effort.

[els]

sorry for the delayed response ...

On the issue of POSH, microformats, RDF OWL - you guys lead and I will
follow. I am not an expert on semantic markups and parsing
microformats, but I am willing to support any "itemized transaction
record" markup, syntax or structure that is decided to be reasonable.

I personally like to keep things simple, so microformats seem
unnecessarily too detailed to me. But it should be a simple matter of
creating a translator from the Prowl format to whatever the "om
standard" turns out to be.

On Mar 25, 10:13 pm, "Guillaume P. Lebleu" <guilla...@lebleu.org>
wrote:

[els]

You have raised really interesting observations and questions. I felt
that the best way to respond is to break my answer into new threads
for each separate topic that you have raised - my apologies in advance
for potentially flooding your mail with new posts.

In general, my answers are summarized by two illustrations (detailed
explanations to be found in the new threads as mentioned above):

Currency IS Architecture @ http://tyaga.org/docs/pix/prowl_layers_20090405.jpg
Prowl vs.Twollar Layers @ http://tyaga.org/docs/pix/prowl_vs_twollar_20090405.jpg

Please zoom in/out of picture for best resolution - I don't really
have time to accomodate different browser behaviors for these quick
presentations.

On Mar 31, 5:48 pm, Miles Thompson <utu...@gmail.com> wrote:
> Edgar,
>

> First off let me mention that I found thishttp://tyaga.org/prowl/obs_sequence.php and thishttp://tyaga.org/prowl/prowl_doc.phpto be heplful for anyone that may have

> Edgar have a read of the pricinciples.. do they look attractive to you?http://microformats.org/wiki/principles

>
> We should also wonder to what extent we are doing would (even potentially)

> overlap with rel-paymenthttp://microformats.org/wiki/rel-payment

> Mileshttp://milo.graytime.org

>
> On Sat, Mar 28, 2009 at 9:53 AM, Guillaume P. Lebleu

> <guilla...@lebleu.org>wrote:

> ...
>
> read more »- Hide quoted text -