Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QfU6q-0001O4-VL for bitcoin-development@lists.sourceforge.net; Sat, 09 Jul 2011 09:46:00 +0000 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; Received: from mail-yx0-f175.google.com ([209.85.213.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QfU6q-0001wK-9U for bitcoin-development@lists.sourceforge.net; Sat, 09 Jul 2011 09:46:00 +0000 Received: by yxi19 with SMTP id 19so1374521yxi.34 for ; Sat, 09 Jul 2011 02:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.67.21 with SMTP id p21mr2550074yba.357.1310204754825; Sat, 09 Jul 2011 02:45:54 -0700 (PDT) Received: by 10.151.150.15 with HTTP; Sat, 9 Jul 2011 02:45:54 -0700 (PDT) Date: Sat, 9 Jul 2011 09:45:54 +0000 Message-ID: From: John Smith To: Bitcoin Dev Content-Type: multipart/alternative; boundary=000e0cd51db2fe91a804a79fd0e7 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1QfU6q-0001wK-9U Subject: [Bitcoin-development] Metadata for transactions / address book records X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 09:46:01 -0000 --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,

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

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

For tra= nsactions:

-=A0=A0 std::string description; // A description that the user can giv= e to a transaction, after he sent/received it, for example "ordered eg= gs"

For addresses:

-=A0=A0 bool visibleInInterface; // V= isible in interface; useful to hide old addresses/labels from the lists, wi= thout 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 extensib= le system would be nice.

Any ideas as to what would be the best plac= e 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 handl= ing etc there and would mean even more data files for the user to backup/tr= ack.

JS
--000e0cd51db2fe91a804a79fd0e7--