Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.175 as permitted sender)
	client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com;
	helo=mail-yx0-f175.google.com; 
MIME-Version: 1.0
Date: Sat, 9 Jul 2011 09:45:54 +0000
Message-ID: <CAJNQ0sv1DxT6SmvqXNdaF09Fj=+mcM-RGXUEaFfns5oAeRFkkg@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=000e0cd51db2fe91a804a79fd0e7
Subject: [Bitcoin-development] Metadata for transactions / address book
	records
Precedence: list

--000e0cd51db2fe91a804a79fd0e7
Content-Type: text/plain; charset=ISO-8859-1

Hello devs,

For UI purposes I'd like to be able to associate metadata to transactions
and address book records.

To be clear, this is completely client-side and will never see the block
chain.

For transactions:

-   std::string description; // A description that the user can give to a
transaction, after he sent/received it, for example "ordered eggs"

For addresses:

-   bool visibleInInterface; // Visible in interface; useful to hide old
addresses/labels from the lists, without removing them for lookup purposes

These are my current ideas; probably, more metadata can be useful later on
(accounting category, links to 3rd party services, etc), so an extensible
system would be nice.

Any ideas as to what would be the best place to put this, while minimizing
the core changes?

I'm aware that this could also be implemented completely inside the UI code,
but I'm not sure this is nice, as it would put database handling etc there
and would mean even more data files for the user to backup/track.

JS

--000e0cd51db2fe91a804a79fd0e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello devs,<br><br>For UI purposes I&#39;d like to be able to associate met=
adata to transactions and address book records. <br><br>To be clear, this i=
s completely client-side and will never see the block chain.<br><br>For tra=
nsactions:<br>
<br>-=A0=A0 std::string description; // A description that the user can giv=
e to a transaction, after he sent/received it, for example &quot;ordered eg=
gs&quot;<br><br>For addresses:<br><br>-=A0=A0 bool visibleInInterface; // V=
isible in interface; useful to hide old addresses/labels from the lists, wi=
thout removing them for lookup purposes<br>
<br>These are my current ideas; probably, more metadata can be useful later=
 on (accounting category, links to 3rd party services, etc), so an extensib=
le system would be nice.<br><br>Any ideas as to what would be the best plac=
e to put this, while minimizing the core changes? <br>
<br>I&#39;m aware that this could also be implemented completely inside the=
 UI code, but I&#39;m not sure this is nice, as it would put database handl=
ing etc there and would mean even more data files for the user to backup/tr=
ack.<br>
<br>JS<br>

--000e0cd51db2fe91a804a79fd0e7--