***From Miles:
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?
***
The issue of "shared accounts", such as a URL representing a multi-
user blog, is not within the scope of Prowl. Those users would need to
set-up an accounting system that addresses their particular
requirements, such as for establishing an "independent currency brand"
that they want to use for purchasing products/services in the market.
In essence, an accounting system would need to control what
transcation records are puiblished in a domain such as "A-Team.org".
If those users have problems managing their accounts and transaction
authorization through a single URL such as "A-Team.org", then each
user could decide to use a different URL such as "A-Team.org/MrT", "A-
Team.org/User2", etc.
But then in a marketplace concerned with accountable reputation, I
predict that the general public would be more concerned about the
market performance of "A-Team.org", rather than ascertaining ".../MrT"
or ".../User2's" individual reputation. From this viewpoint, I say
that although Prowl is usable for establishing and maintaining
"personal" currency brands, Prowl is really intended for establishing
and auditing the accountability of **entity** currency brands. In my
opinion, this is the only way for each independent currency brand
could to have accountable value: an entity declares a market
specialization and its self-determined limits (i.e., budgets) that it
intends to self-regulate against.
Aliases and Separation of Concerns:
I think that "shorter" ids for URL-based transactor identities would
backfire in the long run. The goal of a currency issuer is to
establish **a** reputable currency brand that is widely accepted by
market participants. It would not help to have transaction records
that should demonstrate "A-Team.org's" market performance and
reputation be aliased with "
bit.ly/AT" for various reasons. Just look
at how companies, nonprofits, government agencies, cooperatives, etc.
try to maintain **brand recognition** - why should we expect a brand-
concious organization such as
starbucks.com,
apple.com or
microsoft.com to want to use an alias?
If the goal is to optimize user experience in terms of entering
transaction records on their personal device - PCs or cell phones,
etc. - then leave it to the "Device" layer application to figure that
issue out. Higher "layers", such as the "Entity" and "Reporter"
applications illustrated @
http://tyaga.org/docs/pix/prowl_layers_20090405.jpg,
should not be burdened with those concerns. Instead, those layers
should emphasize the presentation of highly readable published records.