* [Bitcoin-development] Random order for clients page
@ 2012-07-09 15:54 Amir Taaki
2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 17:33 ` Nils Schneider
0 siblings, 2 replies; 24+ messages in thread
From: Amir Taaki @ 2012-07-09 15:54 UTC (permalink / raw)
To: bitcoin-development
Took me a while, but finally got it working.
Entries on the clients page are randomly ordered when the page is generated.
https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 15:54 [Bitcoin-development] Random order for clients page Amir Taaki
@ 2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 16:09 ` Amir Taaki
2012-07-09 20:44 ` Jeff Garzik
2012-07-09 17:33 ` Nils Schneider
1 sibling, 2 replies; 24+ messages in thread
From: Gregory Maxwell @ 2012-07-09 16:04 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki <zgenjix@yahoo•com> wrote:
> Took me a while, but finally got it working.
> Entries on the clients page are randomly ordered when the page is generated.
> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
If you had authored this as a pull request rather than making the
change unilaterally I would have recommended leaving it so the
reference client was always first. I also would have suggested that it
use JS randomization instead of jekyll in order to get more even
coverage, though I think thats a more minor point.
Some people were concerned when this page was created that it would
just be a source of useless disputes. I think its becoming clear that
this is the case. I think the cost of dealing with this page is
starting to exceed the benefit it provides and we should probably
consider removing it.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 16:04 ` Gregory Maxwell
@ 2012-07-09 16:09 ` Amir Taaki
2012-07-09 16:39 ` Stefan Thomas
2012-07-09 17:46 ` Gregory Maxwell
2012-07-09 20:44 ` Jeff Garzik
1 sibling, 2 replies; 24+ messages in thread
From: Amir Taaki @ 2012-07-09 16:09 UTC (permalink / raw)
To: bitcoin-development
JS randomisation is bad. People shouldn't need JS to view a webpage.
Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is.
You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards).
If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website.
Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now.
----- Original Message -----
From: Gregory Maxwell <gmaxwell@gmail•com>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Monday, July 9, 2012 5:04 PM
Subject: Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki <zgenjix@yahoo•com> wrote:
> Took me a while, but finally got it working.
> Entries on the clients page are randomly ordered when the page is generated.
> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
If you had authored this as a pull request rather than making the
change unilaterally I would have recommended leaving it so the
reference client was always first. I also would have suggested that it
use JS randomization instead of jekyll in order to get more even
coverage, though I think thats a more minor point.
Some people were concerned when this page was created that it would
just be a source of useless disputes. I think its becoming clear that
this is the case. I think the cost of dealing with this page is
starting to exceed the benefit it provides and we should probably
consider removing it.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 16:09 ` Amir Taaki
@ 2012-07-09 16:39 ` Stefan Thomas
2012-07-09 16:55 ` Harald Schilly
2012-07-09 17:46 ` Gregory Maxwell
1 sibling, 1 reply; 24+ messages in thread
From: Stefan Thomas @ 2012-07-09 16:39 UTC (permalink / raw)
To: bitcoin-development
> You are not a developer of any alternative clients
I am and I'm going to have to agree with Greg. Information about clients
is bound to be transient and controversial.
My relatively naive suggestion would be to move it to the Wiki. If it
can handle the controversies involved with the Trade page, it should
easily be able to handle the controversies involved with a Clients page
like this one. A link to that page could be added under Bitcoin Wiki on
Bitcoin.org.
On the subject of randomization, I think that's a bad idea. Randomness
does not equal fairness and more importantly it does not serve the
users, which should be the overriding concern. As a user I don't want to
be recommended a random client but the most sensible choice. As
alternative client implementors we should not be overly concerned about
Bitcoin.org recommending the wrong client, truly good clients will
benefit from word-of-mouth and eventually rise to the top. If you want a
"fair" ordering, then I'd order by number of downloads for downloadable
clients and Alexa rank for any hosted / online services if it were
decided that such should be listed at all.
On 7/9/2012 6:09 PM, Amir Taaki wrote:
> JS randomisation is bad. People shouldn't need JS to view a webpage.
>
> Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is.
>
> You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards).
>
> If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website.
>
> Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now.
>
>
>
> ----- Original Message -----
> From: Gregory Maxwell <gmaxwell@gmail•com>
> To: Amir Taaki <zgenjix@yahoo•com>
> Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
> Sent: Monday, July 9, 2012 5:04 PM
> Subject: Re: [Bitcoin-development] Random order for clients page
>
> On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki <zgenjix@yahoo•com> wrote:
>> Took me a while, but finally got it working.
>> Entries on the clients page are randomly ordered when the page is generated.
>> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
>> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
> If you had authored this as a pull request rather than making the
> change unilaterally I would have recommended leaving it so the
> reference client was always first. I also would have suggested that it
> use JS randomization instead of jekyll in order to get more even
> coverage, though I think thats a more minor point.
>
> Some people were concerned when this page was created that it would
> just be a source of useless disputes. I think its becoming clear that
> this is the case. I think the cost of dealing with this page is
> starting to exceed the benefit it provides and we should probably
> consider removing it.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 16:39 ` Stefan Thomas
@ 2012-07-09 16:55 ` Harald Schilly
2012-07-09 17:21 ` Luke-Jr
0 siblings, 1 reply; 24+ messages in thread
From: Harald Schilly @ 2012-07-09 16:55 UTC (permalink / raw)
To: Stefan Thomas; +Cc: bitcoin-development
On Mon, Jul 9, 2012 at 6:39 PM, Stefan Thomas <moon@justmoon•de> wrote:
> As a user I don't want to
> be recommended a random client but the most sensible choice.
> ... wiki page ...
I think this is indeed a controversal topic. I just want to add the
remark, that it would make sense to have the wiki page *and* this more
"official" page. I would envision this official page as some kind of
"stamp of approval" which includes some sensible criteria, e.g. it
works for many users, the development hasn't stopped some time ago
(bitrot), code review, the author(s) is/are known to the community,
private keys aren't accessible by the webservice, etc.
The ordering should be by alphabet, in a vertical list with a short
unbiased description.
Harald
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 16:55 ` Harald Schilly
@ 2012-07-09 17:21 ` Luke-Jr
0 siblings, 0 replies; 24+ messages in thread
From: Luke-Jr @ 2012-07-09 17:21 UTC (permalink / raw)
To: bitcoin-development; +Cc: Harald Schilly
FWIW, all this argumenting is why my original suggestion for a Clients list
focussed on objective information in alphabetical order.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 15:54 [Bitcoin-development] Random order for clients page Amir Taaki
2012-07-09 16:04 ` Gregory Maxwell
@ 2012-07-09 17:33 ` Nils Schneider
2012-07-09 18:24 ` Amir Taaki
1 sibling, 1 reply; 24+ messages in thread
From: Nils Schneider @ 2012-07-09 17:33 UTC (permalink / raw)
To: bitcoin-development
I don't think that's a good idea as it can easily confuse or annoy users
when things move around. The ordering should be preserved as much as
possible so users can remember where they found a client they liked
(e.g. 2nd row, 1st column and screenshot with light and blue colors).
Making them search the entire page is inefficient and will just get
worse once there are many clients on the page (and I think that's the goal).
On 09.07.2012 17:54, Amir Taaki wrote:
> Took me a while, but finally got it working.
>
> Entries on the clients page are randomly ordered when the page is generated.
>
> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
>
> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 16:09 ` Amir Taaki
2012-07-09 16:39 ` Stefan Thomas
@ 2012-07-09 17:46 ` Gregory Maxwell
2012-07-09 18:03 ` Alan Reiner
2012-07-09 18:18 ` Amir Taaki
1 sibling, 2 replies; 24+ messages in thread
From: Gregory Maxwell @ 2012-07-09 17:46 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> JS randomisation is bad. People shouldn't need JS to view a webpage.
JS randomization doesn't imply needing JS to view the page. It implies
needing JS to see it in random order. You could also combine it with
the server-side randomization if you care about non-js being non
random, though I don't think it matters.
As others have pointed out I don't generally think the randomization
is good in principle, but if its done it should at least achieve its
goals.
> Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is.
I'll let other people speak for themselves, but I did consult others
before reverting your last batch of changes.
More generally, we have pull requests in order to get some peer review
of changes. Everyone should use them except for changes which are
urgent or trivially safe. (Presumably everyone with access knows how
to tell if their changes are likely to be risky or controversial)
> You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards).
I'm strongly supportive diversity in the Bitcoin network, and some alt
client developers can speak to the positive prodding I've given them
towards becoming more complete software. If I've said anything that
suggests otherwise I'd love to be pointed to it in order to clarify my
position.
Unfortunately none of the primary alternatives are yet complete, the
network would be non-function if it consisted entirely of multibit or
electrum nodes (and as you've noted armory uses a local reference
client as its 'server'). The distinction between multiple kinds of
clients in terms of security and network health are subtle and can be
difficult to explain even to technical users and so until something
changes there the reference client needs to be the option we lead
with. People should us it unless their use-case doesn't match. When it
does they'll know it and they'll be looking. We don't need to make one
of those recommendations a primary option.
I like the proposals of moving this stuff to the Wiki as the wiki
already contains tons of questionable (and sometimes contradictory)
advice and so there is less expectation that placement there implies
any vetting.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 17:46 ` Gregory Maxwell
@ 2012-07-09 18:03 ` Alan Reiner
2012-07-09 18:29 ` thomasV1
2012-07-09 18:18 ` Amir Taaki
1 sibling, 1 reply; 24+ messages in thread
From: Alan Reiner @ 2012-07-09 18:03 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4650 bytes --]
I generally agree with Greg. I don't see anything he's said or done as
anti-alt-client.
As an alt-client developer, I'm happy to see my client on the main page,
but I'm also happy if that "clients" page is simply an acknowledgement that
there's more to the Bitcoin world than just the Bitcoin-Qt client, and a
link of where to find more information (i.e. the wiki). I would still *
prefer* to have the page the way it is, because I think alt clients should
be more accessible and word will spread better where it is now -- but I
also recognize the inherent difficulty of gaining any kind of consensus of
how it should be organized, what goes on the list, etc, and no matter how
you do it, someone will complain about it being unfair or not right.
We either have to have a "czar" who is trusted to make responsible
decisions, and complaints of being unfair or recommendations for
improvements can go through that person, but ultimately it is that person
who makes the call. Or we just move it to another page that is less
strictly controlled and where these things matter less. Trying to gain
consensus among an amalgamation of developers all with competing priorities
and "products" is a terrible way to try to agree on stuff.
-Alan
On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> > JS randomisation is bad. People shouldn't need JS to view a webpage.
>
> JS randomization doesn't imply needing JS to view the page. It implies
> needing JS to see it in random order. You could also combine it with
> the server-side randomization if you care about non-js being non
> random, though I don't think it matters.
>
> As others have pointed out I don't generally think the randomization
> is good in principle, but if its done it should at least achieve its
> goals.
>
> > Only you have a problem with this page. I don't see why Bitcoin-Qt needs
> to be first either when it dominates the front page. It is perfectly fine
> as it is.
>
> I'll let other people speak for themselves, but I did consult others
> before reverting your last batch of changes.
>
> More generally, we have pull requests in order to get some peer review
> of changes. Everyone should use them except for changes which are
> urgent or trivially safe. (Presumably everyone with access knows how
> to tell if their changes are likely to be risky or controversial)
>
> > You are not a developer of any alternative clients, and this is a
> webpage for Bitcoin clients. I have made a change to remove a source of
> disputes, and make the process more fair and equal. Your suggestion to
> remove the clients page is your bias towards thinking that there should be
> only one Bitcoin client that everyone uses (the one which you contribute
> towards).
>
> I'm strongly supportive diversity in the Bitcoin network, and some alt
> client developers can speak to the positive prodding I've given them
> towards becoming more complete software. If I've said anything that
> suggests otherwise I'd love to be pointed to it in order to clarify my
> position.
>
> Unfortunately none of the primary alternatives are yet complete, the
> network would be non-function if it consisted entirely of multibit or
> electrum nodes (and as you've noted armory uses a local reference
> client as its 'server'). The distinction between multiple kinds of
> clients in terms of security and network health are subtle and can be
> difficult to explain even to technical users and so until something
> changes there the reference client needs to be the option we lead
> with. People should us it unless their use-case doesn't match. When it
> does they'll know it and they'll be looking. We don't need to make one
> of those recommendations a primary option.
>
> I like the proposals of moving this stuff to the Wiki as the wiki
> already contains tons of questionable (and sometimes contradictory)
> advice and so there is less expectation that placement there implies
> any vetting.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 5730 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 17:46 ` Gregory Maxwell
2012-07-09 18:03 ` Alan Reiner
@ 2012-07-09 18:18 ` Amir Taaki
2012-07-09 18:30 ` Mike Hearn
2012-07-09 18:48 ` [Bitcoin-development] Random order for clients page Gregory Maxwell
1 sibling, 2 replies; 24+ messages in thread
From: Amir Taaki @ 2012-07-09 18:18 UTC (permalink / raw)
To: bitcoin-development
This page really does matter to alternative clients. If you measure the click through statistics, then they are a significant portion of the
traffic. By removing this page, you are directly stunting Bitcoin's
growth.
The only thing that's changed between now and this morning is:
- Addition of Bitcoin Wallet for Android
- Randomisation of entries
I actually got permission from everyone involved before making the page.If you want to remove the page, then we should see a vote by:
- laanwj
- gavin
- sipa
- jgarzik
- BlueMatt
- Diapolo
- luke-jr
- you
- jim from multibit
- gary rowe
- ThomasV
- me
- etotheipi
- Andreas Schildbach
- justmoon
- Mike Hearn
You're proposing to remove the page. You know, and I know and I know that you know that nobody visits the Wiki. Your proposal is not "move to Wiki" really but remove from bitcoin.org. Keep bitcoin.org for Bitcoin-Qt only which is against the stated goals of the rest of your team members (gavin, sipa, jgarzik).
Have you tried the new clients? I've tried all 4, and they are all well written.
Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's more featureful and secure than Bitcoin-Qt what with deterministic wallets, brain-wallets, prioritising addresses, frozen addresses, offline transactions - none of which Bitcoin-Qt has.
MultiBit is also very good with QR integration and the ability for merchants to quickly set themselves up. It's full of guiding help text, and has this paradigm to allow people to work with keys.
Bitcoin Wallet for Android has one of the best bitcoin UIs I've seen and is extremely well thought out in how the user navigates through the software.
The Bitcoin network could function perfectly fine with Electrum nodes and
miners. You would still have miners and we wouldn't have the problem now with huge blocks because miners would be economically incentivised to
keep blocks small. But that's another discussion.
Technically speaking, the randomisation is fine now. It achieves its intended effect, as the page is regenerated daily.
This does not need to be a source of arguing. I see no problem with having this page be a neutral overview of the main clients (as we all agreed together in the beginning):
- Source must be public, and users must be able to run from source.
- Description should be non-spammy and neutral sounding. Cover the negative aspects.
Randomisation of the order simply makes that fairer. Alphabetical is not a good option (as others have suggested) because it can be gamed.
There is absolutely no reason to remove this page unless you think bitcoin.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and the long-term stated goal of bitcoin.org as a neutral resource for the community.
----- Original Message -----
From: Gregory Maxwell <gmaxwell@gmail•com>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Monday, July 9, 2012 6:46 PM
Subject: Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> JS randomisation is bad. People shouldn't need JS to view a webpage.
JS randomization doesn't imply needing JS to view the page. It implies
needing JS to see it in random order. You could also combine it with
the server-side randomization if you care about non-js being non
random, though I don't think it matters.
As others have pointed out I don't generally think the randomization
is good in principle, but if its done it should at least achieve its
goals.
> Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is.
I'll let other people speak for themselves, but I did consult others
before reverting your last batch of changes.
More generally, we have pull requests in order to get some peer review
of changes. Everyone should use them except for changes which are
urgent or trivially safe. (Presumably everyone with access knows how
to tell if their changes are likely to be risky or controversial)
> You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards).
I'm strongly supportive diversity in the Bitcoin network, and some alt
client developers can speak to the positive prodding I've given them
towards becoming more complete software. If I've said anything that
suggests otherwise I'd love to be pointed to it in order to clarify my
position.
Unfortunately none of the primary alternatives are yet complete, the
network would be non-function if it consisted entirely of multibit or
electrum nodes (and as you've noted armory uses a local reference
client as its 'server'). The distinction between multiple kinds of
clients in terms of security and network health are subtle and can be
difficult to explain even to technical users and so until something
changes there the reference client needs to be the option we lead
with. People should us it unless their use-case doesn't match. When it
does they'll know it and they'll be looking. We don't need to make one
of those recommendations a primary option.
I like the proposals of moving this stuff to the Wiki as the wiki
already contains tons of questionable (and sometimes contradictory)
advice and so there is less expectation that placement there implies
any vetting.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 17:33 ` Nils Schneider
@ 2012-07-09 18:24 ` Amir Taaki
0 siblings, 0 replies; 24+ messages in thread
From: Amir Taaki @ 2012-07-09 18:24 UTC (permalink / raw)
To: bitcoin-development
By that time in the future, when there are many clients, there should just be a flat list or no list at all.
----- Original Message -----
From: Nils Schneider <nils@nilsschneider•net>
To: bitcoin-development@lists•sourceforge.net
Cc:
Sent: Monday, July 9, 2012 6:33 PM
Subject: Re: [Bitcoin-development] Random order for clients page
I don't think that's a good idea as it can easily confuse or annoy users
when things move around. The ordering should be preserved as much as
possible so users can remember where they found a client they liked
(e.g. 2nd row, 1st column and screenshot with light and blue colors).
Making them search the entire page is inefficient and will just get
worse once there are many clients on the page (and I think that's the goal).
On 09.07.2012 17:54, Amir Taaki wrote:
> Took me a while, but finally got it working.
>
> Entries on the clients page are randomly ordered when the page is generated.
>
> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
>
> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 18:03 ` Alan Reiner
@ 2012-07-09 18:29 ` thomasV1
0 siblings, 0 replies; 24+ messages in thread
From: thomasV1 @ 2012-07-09 18:29 UTC (permalink / raw)
To: bitcoin-development
I agree with Alan.
I too am happy to see my client listed on bitcoin.org, and I don't mind Bitcoin-Qt being listed first. I have no problem with a "czar" approach if it can solve conflicts.
I believe that it is useful to keep the 'clients' page on bitcoin.org, because it contributes to clarifying the difference between the Bitcoin client and Bitcoin as a protocol/network/ecosystem. It shows that Bitcoin is much more than its original implementation. It is a sign of health.
Thomas
-------- Original-Nachricht --------
> Datum: Mon, 9 Jul 2012 14:03:55 -0400
> Von: Alan Reiner <etotheipi@gmail•com>
> An: Gregory Maxwell <gmaxwell@gmail•com>
> CC: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
> Betreff: Re: [Bitcoin-development] Random order for clients page
> I generally agree with Greg. I don't see anything he's said or done as
> anti-alt-client.
>
> As an alt-client developer, I'm happy to see my client on the main page,
> but I'm also happy if that "clients" page is simply an acknowledgement
> that
> there's more to the Bitcoin world than just the Bitcoin-Qt client, and a
> link of where to find more information (i.e. the wiki). I would still *
> prefer* to have the page the way it is, because I think alt clients should
> be more accessible and word will spread better where it is now -- but I
> also recognize the inherent difficulty of gaining any kind of consensus of
> how it should be organized, what goes on the list, etc, and no matter how
> you do it, someone will complain about it being unfair or not right.
>
> We either have to have a "czar" who is trusted to make responsible
> decisions, and complaints of being unfair or recommendations for
> improvements can go through that person, but ultimately it is that person
> who makes the call. Or we just move it to another page that is less
> strictly controlled and where these things matter less. Trying to gain
> consensus among an amalgamation of developers all with competing
> priorities
> and "products" is a terrible way to try to agree on stuff.
>
> -Alan
>
>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 18:18 ` Amir Taaki
@ 2012-07-09 18:30 ` Mike Hearn
2012-07-09 22:26 ` Stefan Thomas
2012-07-09 18:48 ` [Bitcoin-development] Random order for clients page Gregory Maxwell
1 sibling, 1 reply; 24+ messages in thread
From: Mike Hearn @ 2012-07-09 18:30 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
It's easy to say, this page is controversial, so let's get rid of it.
However that starts the project down the road of being dominated by
our internal politics rather than what actually makes sense from the
end users perspective. That route spells doom for any product. You can
always tell when a UI or product is the result of internal politics,
whether it be the difficulty of plug-n-play hardware on Linux (no
driver api) to how Microsoft is incapable of producing anything that
isn't built on Windows. Gmail labs is another example of this.
It makes sense that if I go to bitcoin.org, I am educated about the
system and what is available for it. It doesn't make any sense to have
some stuff on the main site and other stuff on a wiki (which may get
randomly vandalized and looks less professional), based on how
"controversial" some developers find it.
FWIW I am dead set against anyone randomly changing the website
without a pull request and such changes should be reverted and
resubmitted through the proper channels. I don't perceive much value
in randomization or trying to make this page "fair". If anything, we
need to pick somebody (one person) who has a strong focus on regular
people and their needs, then just make them the sole committer to the
website. That way disputes can be resolved by them making a decision,
instead of ridiculous edit wars.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 18:18 ` Amir Taaki
2012-07-09 18:30 ` Mike Hearn
@ 2012-07-09 18:48 ` Gregory Maxwell
1 sibling, 0 replies; 24+ messages in thread
From: Gregory Maxwell @ 2012-07-09 18:48 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
On Mon, Jul 9, 2012 at 2:18 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> The only thing that's changed between now and this morning is:
>
> - Addition of Bitcoin Wallet for Android
> - Randomisation of entries
Yes, because I reverted eight commits to it by you because they were
clearly controversial, including the proprietary clients section and
blockchain.info.
You went on to add the randomization, again without a pull request
and, as seen here, its somewhat controversial.
> I actually got permission from everyone involved before making the page.If you want to remove the page, then we should see a vote by:
Luke originally authored the multiple clients page. It sounded like it
could be useful and I made some recommendations for it too. I'm
concerned that it's not working out that well. Thus "we should
probably consider". Perhaps that came off as too strong. If I really
pushing for that I'd submit it as a pull request. (and everyone,
including the people you listed, could comment)
I think the fact that we can just remove it if we can't agree on it is
a useful point to the discussion. For the site to be a neutral
resource it should be conservatively operated and if sometimes being
neutral, safe, and conservative gets in the way of being complete then
we should choose those other things over completeness. There are a
great many other resources available, bitcoin.org will never contain
all the relevant knowledge.
> You're proposing to remove the page.You know, and I know and I know that you know that nobody visits the Wiki.
Crazy. I have considerable evidence to the contrary, in fact. The wiki
is widely used and promoted as the primary community memory.
I certainly didn't agree with that suggestion because I thought it
wouldn't get seen. I found it agreeable because it would reflect the
lower degree of consensus we apparently have about listing the page.
> Have you tried the new clients? I've tried all 4, and they are all well written.
I've used multibit, armory, and electrum (though not for some time). I
shed painted the electrum determinstic wallet stuff pretty extensively
when it was first created, and I think the wordlist seed stuff was my
suggestion.
> Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's more featureful and secure than Bitcoin-Qt what with deterministic wallets, brain-wallets, prioritising addresses, frozen addresses, offline transactions - none of which Bitcoin-Qt has.
I'd like to invite you to point your electrum client against a server
I operate. I will then happily agree with you that it is more secure:
because the bitcoin I rob from you will soothe my pain at the loss of
this "debate". Sound like a deal?
I think you're exaggerating the features there, and simultaneously
underplaying the fact that clients doesn't actually participate in the
bitcoin protocol, don't provide the security promises of bitcoin, and
basically leave us with a centralized system (if thats all we had).
It's a worthwhile part of the ecosystem, I agree.
> MultiBit is also very good with QR integration and the ability for merchants to quickly set themselves up. It's full of guiding help text, and has this paradigm to allow people to work with keys.
There has been QR integration in bitcoin-qt for some time. ::shrugs::
I don't really understand why you're arguing features here: Yes the
other clients are great things. I never said they weren't. They are
not, however, complete alternatives to the reference client yet.
> There is absolutely no reason to remove this page unless you think bitcoin.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and the long-term stated goal of bitcoin.org as a neutral resource for the community.
Please stop putting words in my mouth. I certainly don't think that.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 16:09 ` Amir Taaki
@ 2012-07-09 20:44 ` Jeff Garzik
1 sibling, 0 replies; 24+ messages in thread
From: Jeff Garzik @ 2012-07-09 20:44 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
On Mon, Jul 9, 2012 at 12:04 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> If you had authored this as a pull request rather than making the
> change unilaterally I would have recommended leaving it so the
> reference client was always first. I also would have suggested that it
> use JS randomization instead of jekyll in order to get more even
> coverage, though I think thats a more minor point.
Agreed, and this would be why I support revert -- pull requests are
for anything non-trivial. This practice of pull requests clearly
should be followed in the case of controversial changes.
> Some people were concerned when this page was created that it would
> just be a source of useless disputes. I think its becoming clear that
> this is the case. I think the cost of dealing with this page is
> starting to exceed the benefit it provides and we should probably
> consider removing it.
Agreed.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 18:30 ` Mike Hearn
@ 2012-07-09 22:26 ` Stefan Thomas
2012-07-09 22:37 ` Mike Hearn
2012-07-09 23:07 ` [Bitcoin-development] Wiki client list (was: Random order for clients page) Luke-Jr
0 siblings, 2 replies; 24+ messages in thread
From: Stefan Thomas @ 2012-07-09 22:26 UTC (permalink / raw)
To: bitcoin-development
> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective.
I strongly agree, but this is *why* I suggested moving it to the wiki. I
recently had to choose an XMPP client and I looked on xmpp.org - after a
frustrating experience with their listing [1], I went to Wikipedia who
have an decent feature-based matrix [2].
(There may be better examples, but I'm using this one, because this
actually did happen.)
This is just anecdotal, but there are some reasons why wikis tend to do
a better for this kind of thing is because they are:
- more up-to-date (anyone can update them)
- more in touch with users:
-> Users can edit the page and add a column to a feature matrix for
example).
-> The editing discussions include users. I guarantee there are more
Bitcoin end users with a wiki account than a Github account.
- immediately recognizable as a wiki (thanks to Mediawiki/Wikipedia.)
As such many users will correctly treat and interpret the information
presented as community-generated and fallible.
So they are more user-oriented in the sense that they will be influenced
by a diverse set of backgrounds and views vs. a Github based page which
will be dominated by developers. If you want to see "the result of
internal politics", the current client page is a good example. We
couldn't agree on the columns for a feature matrix, so now we just have
walls of text. Some of the options that are de-facto the most popular
with users like BlockChain.info or just using your MtGox account are not
mentioned at all. When analyzing client security, Greg discussed
counterparty risks but ignored other risk factors like default backup
behavior and the usability of security features.
But even if I grant you that those clients' overall risk profile is
worse than Bitcoin-Qt's, maybe I'm happy to take that risk in exchange
for less setup/maintenance effort. Based on our support requests at
WeUseCoins I know that there are tons of users with < 1 BTC in their
wallets. If my hourly wage is 20$ and I have 20$ in my Bitcoin wallet
then spending one hour per month downloading/updating/figuring-out the
client is equivalent to a total loss.
The list is obviously designed by open-source developers and that's
fine, it's bitcoin.org, arguably we *should* try to push users in a
specific direction, arguably we *should* err on the side of caution in
order to not be caught recommending a hosted wallet that gets hacked.
But if user orientation is supposed to be the focus, then the wiki will
both allow us (because it's less "official") and force us (because users
will have a say) to include even clients we personally wouldn't use. :)
[1] http://xmpp.org/xmpp-software/clients/
[2]
http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP-related_features
On 7/9/2012 8:30 PM, Mike Hearn wrote:
> It's easy to say, this page is controversial, so let's get rid of it.
>
> However that starts the project down the road of being dominated by
> our internal politics rather than what actually makes sense from the
> end users perspective. That route spells doom for any product. You can
> always tell when a UI or product is the result of internal politics,
> whether it be the difficulty of plug-n-play hardware on Linux (no
> driver api) to how Microsoft is incapable of producing anything that
> isn't built on Windows. Gmail labs is another example of this.
>
> It makes sense that if I go to bitcoin.org, I am educated about the
> system and what is available for it. It doesn't make any sense to have
> some stuff on the main site and other stuff on a wiki (which may get
> randomly vandalized and looks less professional), based on how
> "controversial" some developers find it.
>
> FWIW I am dead set against anyone randomly changing the website
> without a pull request and such changes should be reverted and
> resubmitted through the proper channels. I don't perceive much value
> in randomization or trying to make this page "fair". If anything, we
> need to pick somebody (one person) who has a strong focus on regular
> people and their needs, then just make them the sole committer to the
> website. That way disputes can be resolved by them making a decision,
> instead of ridiculous edit wars.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 22:26 ` Stefan Thomas
@ 2012-07-09 22:37 ` Mike Hearn
2012-07-10 2:36 ` Stefan Thomas
2012-07-09 23:07 ` [Bitcoin-development] Wiki client list (was: Random order for clients page) Luke-Jr
1 sibling, 1 reply; 24+ messages in thread
From: Mike Hearn @ 2012-07-09 22:37 UTC (permalink / raw)
To: Stefan Thomas; +Cc: bitcoin-development
> I strongly agree, but this is *why* I suggested moving it to the wiki. I
> recently had to choose an XMPP client and I looked on xmpp.org - after a
> frustrating experience with their listing [1]
Probably because their listing is even more useless than any of the
proposals that were presented here. Thank goodness it didn't end up
like that. Their table doesn't even attempt to list features or
differentiating aspects of each client.
I think the XMPP guys have pretty much given up on directly marketing
the system to end users.
> - more up-to-date (anyone can update them)
Fortunately reasonable clients don't appear/disappear/change that often.
> - more in touch with users:
I think by "users" you mean, geeks who understand wiki syntax. Because
that's what it'll end up trending towards. I don't believe a wiki
would reflect the needs of your average person. It's still better to
have these arguments here and try to find a user-focussed consensus
than hope one will converge from a wiki.
> If you want to see "the result of
> internal politics", the current client page is a good example. We
> couldn't agree on the columns for a feature matrix, so now we just have
> walls of text.
Inability to agree on columns isn't why the page looks like that. I
know because I'm the one who argued for the current design.
It looks like that because feature matrices aren't especially helpful
for newbies to make a decision, especially when the "features" in
question were often things like how they handled the block chain or
which protocol standards they support, ie, things only of interest to
developers.
It's much easier to communicate the differences to people with a short
piece of text, and maybe if there is no obvious way to explain why
you'd want to use a given client, that's a good sign it's not worth
listing there. Otherwise you end up like xmpp.org.
> Some of the options that are de-facto the most popular
> with users like BlockChain.info or just using your MtGox account are not
> mentioned at all.
It's true that bitcoin.org needs to be conservative. That said, I'd
like there to be sections for them too, actually. I agree that risk
isn't purely about how it's implemented and that whilst we might like
to push particular ideologies around protocols or code licensing, that
isn't especially relevant to end users who have different priorities.
Track record counts for a lot as well.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bitcoin-development] Wiki client list (was: Random order for clients page)
2012-07-09 22:26 ` Stefan Thomas
2012-07-09 22:37 ` Mike Hearn
@ 2012-07-09 23:07 ` Luke-Jr
1 sibling, 0 replies; 24+ messages in thread
From: Luke-Jr @ 2012-07-09 23:07 UTC (permalink / raw)
To: bitcoin-development
https://en.bitcoin.it/wiki/Clients
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-09 22:37 ` Mike Hearn
@ 2012-07-10 2:36 ` Stefan Thomas
2012-07-10 2:44 ` Alan Reiner
0 siblings, 1 reply; 24+ messages in thread
From: Stefan Thomas @ 2012-07-10 2:36 UTC (permalink / raw)
To: bitcoin-development
> I think by "users" you mean, geeks who understand wiki syntax.
The point is to expand the circle of contributors. I'm pretty sure there
are more people who can edit a wiki than people who know HTML and how to
create a git pull request. :)
> Inability to agree on columns isn't why the page looks like that.
My apologies, I vaguely remembered Luke's original proposal and that it
got rejected, but you're correct, the reason wasn't a debate on the
columns but that people didn't like the feature matrix at all.
I didn't really mean to argue on the details of what the page should
look like, but just to briefly respond to Mike's point:
> It looks like that because feature matrices aren't especially helpful
> for newbies to make a decision, especially when the "features" in
> question were often things like how they handled the block chain or
> which protocol standards they support, ie, things only of interest to
> developers.
A well-designed feature matrix can quite useful and user-friendly.
http://www.apple.com/ipod/compare-ipod-models/
Prose is better to get a sense of the philosophy and basic idea of a
client. If it was between having only a feature matrix or only prose,
I'd probably go for the prose as well.
What a feature matrix is good at though is it allows you to very quickly
find the specific feature or general criteria you're looking for without
reading through all of the text. So it might be a useful addition maybe
not on Bitcoin.org, but certainly on the wiki.
On 7/10/2012 12:37 AM, Mike Hearn wrote:
>> I strongly agree, but this is *why* I suggested moving it to the wiki. I
>> recently had to choose an XMPP client and I looked on xmpp.org - after a
>> frustrating experience with their listing [1]
> Probably because their listing is even more useless than any of the
> proposals that were presented here. Thank goodness it didn't end up
> like that. Their table doesn't even attempt to list features or
> differentiating aspects of each client.
>
> I think the XMPP guys have pretty much given up on directly marketing
> the system to end users.
>
>> - more up-to-date (anyone can update them)
> Fortunately reasonable clients don't appear/disappear/change that often.
>
>> - more in touch with users:
> I think by "users" you mean, geeks who understand wiki syntax. Because
> that's what it'll end up trending towards. I don't believe a wiki
> would reflect the needs of your average person. It's still better to
> have these arguments here and try to find a user-focussed consensus
> than hope one will converge from a wiki.
>
>> If you want to see "the result of
>> internal politics", the current client page is a good example. We
>> couldn't agree on the columns for a feature matrix, so now we just have
>> walls of text.
> Inability to agree on columns isn't why the page looks like that. I
> know because I'm the one who argued for the current design.
>
> It looks like that because feature matrices aren't especially helpful
> for newbies to make a decision, especially when the "features" in
> question were often things like how they handled the block chain or
> which protocol standards they support, ie, things only of interest to
> developers.
>
> It's much easier to communicate the differences to people with a short
> piece of text, and maybe if there is no obvious way to explain why
> you'd want to use a given client, that's a good sign it's not worth
> listing there. Otherwise you end up like xmpp.org.
>
>> Some of the options that are de-facto the most popular
>> with users like BlockChain.info or just using your MtGox account are not
>> mentioned at all.
> It's true that bitcoin.org needs to be conservative. That said, I'd
> like there to be sections for them too, actually. I agree that risk
> isn't purely about how it's implemented and that whilst we might like
> to push particular ideologies around protocols or code licensing, that
> isn't especially relevant to end users who have different priorities.
> Track record counts for a lot as well.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-10 2:36 ` Stefan Thomas
@ 2012-07-10 2:44 ` Alan Reiner
2012-07-10 3:05 ` Gregory Maxwell
0 siblings, 1 reply; 24+ messages in thread
From: Alan Reiner @ 2012-07-10 2:44 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
On 07/09/2012 10:36 PM, Stefan Thomas wrote:
>> It looks like that because feature matrices aren't especially helpful
>> for newbies to make a decision, especially when the "features" in
>> question were often things like how they handled the block chain or
>> which protocol standards they support, ie, things only of interest to
>> developers.
> A well-designed feature matrix can quite useful and user-friendly.
>
> http://www.apple.com/ipod/compare-ipod-models/
>
> Prose is better to get a sense of the philosophy and basic idea of a
> client. If it was between having only a feature matrix or only prose,
> I'd probably go for the prose as well.
>
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org, but certainly on the wiki.
>
If we're keeping the clients page, I would really like to see the
feature matrix linked from that page. It shouldn't be on that main
clients page (for the reasons already stated), but Stefan makes a point
that /it is really useful for many users./ Add "Compare features of the
various different clients here: <link>" and users who will benefit will
most definitely click on it. I think that's win-win.
[-- Attachment #2: Type: text/html, Size: 1869 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-10 2:44 ` Alan Reiner
@ 2012-07-10 3:05 ` Gregory Maxwell
2012-07-10 7:12 ` Wladimir
2012-07-10 9:11 ` Stefan Thomas
0 siblings, 2 replies; 24+ messages in thread
From: Gregory Maxwell @ 2012-07-10 3:05 UTC (permalink / raw)
To: Alan Reiner; +Cc: bitcoin-development
On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org, but certainly on the wiki.
I'm generally not a fan of feature matrixes, they encourage "checkbox
decision making"— which is seldom very good for the decider, though
it's much loved by the marketing department that puts together the
matrix. But just becase something is loved by marketing departments
for its ability to set the agenda in variously biased ways doesn't
mean its a great thing to emulate.
Take the matrix Luke linked to for example[1]. Now imagine that we
tunnel MyBitcoin from a year ago and drop it into that table. It
would have every light green, except 'encryption' (which wouldn't have
been green for bitcoin-qt then either). It would basically be the
dominant option by the matrix comparison, and this is without any
lobbying to get MyBitcoin specific features (like their shopping chart
interface) added, not to mention the "_vanishes with everyone's
money_" feature.
I don't think I'm being unreasonable to say that if you could drop in
something that retrospectively cost people a lot into your decision
matrix and it comes out on top you're doing something wrong.
In tables like this significant differences like "a remote hacker can
rob you" get reduced to equal comparison with "chrome spoiler", and
it further biases development motivations towards features that make
nice bullets (even if they're seldom used) vs important infrastructure
which may invisibly improve usage every day or keeps the network
secure and worth having. "Of course I want the fastest startup! Why
would I choose anything else?" "What do you mean all my bitcoin is
gone because the four remaining full nodes were taken over and reorged
it all?"
I wouldn't expect any really important features which don't have
complicated compromises attached to them to be omitted from all
clients for all that long.
Basically matrixes make bad decision making fast, and by making it
fast it's more attractive than careful decision making that always
takes time. The text is nice because it contextualizes the complete
feature set and helps you understand why different clients exist, what
problems they attempt to solve, and what compromises they make. ...
without making the unrealistic demand of the user they they know how
to fairly weigh the value of technical and sometimes subtle issues.
[1] https://en.bitcoin.it/wiki/Clients
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-10 3:05 ` Gregory Maxwell
@ 2012-07-10 7:12 ` Wladimir
2012-07-10 9:11 ` Stefan Thomas
1 sibling, 0 replies; 24+ messages in thread
From: Wladimir @ 2012-07-10 7:12 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4617 bytes --]
Just my two cents -- I'm against removing the overview page or moving it to
the wiki. I think other open source clients deserve a mention on the
bitcoin.org page.
Many new people are looking for a good Android client, for example. Rather
than randomly searching on Google or the app store, it's much safer to
follow the link from bitcoin.org. Others are looking for a light clients
because they think the Satoshi one is too heavy.
Again, rather than following random links on a search engine or wiki (not
all users have the common sense required for this) it may be better if they
follow links "audited" (or at least discussed) by this community. I agree
with Jim here.
The reference client is already first in that it can be downloaded directly
from the main page of bitcoin.org. That should stay that way for the
considerable future, as it's the most proven. The position in the alt
clients list is less important. That said, I'm not a big fan of randomized
order because it's confusing. Come back to the page and it's different.
Some other neutral ordering is probably possible.
Wladimir
On Tue, Jul 10, 2012 at 5:05 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> > What a feature matrix is good at though is it allows you to very quickly
> > find the specific feature or general criteria you're looking for without
> > reading through all of the text. So it might be a useful addition maybe
> > not on Bitcoin.org, but certainly on the wiki.
>
> I'm generally not a fan of feature matrixes, they encourage "checkbox
> decision making"— which is seldom very good for the decider, though
> it's much loved by the marketing department that puts together the
> matrix. But just becase something is loved by marketing departments
> for its ability to set the agenda in variously biased ways doesn't
> mean its a great thing to emulate.
>
> Take the matrix Luke linked to for example[1]. Now imagine that we
> tunnel MyBitcoin from a year ago and drop it into that table. It
> would have every light green, except 'encryption' (which wouldn't have
> been green for bitcoin-qt then either). It would basically be the
> dominant option by the matrix comparison, and this is without any
> lobbying to get MyBitcoin specific features (like their shopping chart
> interface) added, not to mention the "_vanishes with everyone's
> money_" feature.
>
> I don't think I'm being unreasonable to say that if you could drop in
> something that retrospectively cost people a lot into your decision
> matrix and it comes out on top you're doing something wrong.
>
> In tables like this significant differences like "a remote hacker can
> rob you" get reduced to equal comparison with "chrome spoiler", and
> it further biases development motivations towards features that make
> nice bullets (even if they're seldom used) vs important infrastructure
> which may invisibly improve usage every day or keeps the network
> secure and worth having. "Of course I want the fastest startup! Why
> would I choose anything else?" "What do you mean all my bitcoin is
> gone because the four remaining full nodes were taken over and reorged
> it all?"
>
> I wouldn't expect any really important features which don't have
> complicated compromises attached to them to be omitted from all
> clients for all that long.
>
> Basically matrixes make bad decision making fast, and by making it
> fast it's more attractive than careful decision making that always
> takes time. The text is nice because it contextualizes the complete
> feature set and helps you understand why different clients exist, what
> problems they attempt to solve, and what compromises they make. ...
> without making the unrealistic demand of the user they they know how
> to fairly weigh the value of technical and sometimes subtle issues.
>
>
> [1] https://en.bitcoin.it/wiki/Clients
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 5818 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-10 3:05 ` Gregory Maxwell
2012-07-10 7:12 ` Wladimir
@ 2012-07-10 9:11 ` Stefan Thomas
2012-07-13 15:20 ` Daniel F
1 sibling, 1 reply; 24+ messages in thread
From: Stefan Thomas @ 2012-07-10 9:11 UTC (permalink / raw)
To: bitcoin-development
> I wouldn't expect any really important features which don't have
> complicated compromises attached to them to be omitted from all
> clients for all that long.
True, it's those compromises that people should base their decision on.
To make that easier was the motivation for me to suggest feature
matrices in the first place.
Right now if I read Electrum's description, it doesn't say anything
about the tradeoffs with a lightweight client like the slightly weaker
privacy guarantees. At best I could deduce that from the fact that
unlike Bitcoin-Qt it doesn't explicitly list privacy as an advantage.
So applying the same "MyBitcoin test" to the current Bitcoin Clients
page and if you want to be fair, we'd have to assume that if it was
indeed included it would also just be a short pitch listing only pros
and no cons. So it would say something like: "MyBitcoin starts instantly
and is really easy to use and great for beginners." etc.
Obviously if you compare a bad matrix to good short descriptions and
vice versa you'll get the conclusion you're trying to get.
I think Alan had the best idea - let's have the Clients page as it is
and have it link to the wiki for those who want a more detailed
comparison. On the wiki page we can then have explanations of the basic
client types, separate matrices for features and for security/privacy
and whatever else might be useful to know when choosing a client. Then
users who don't really care aren't bothered by "too much information"
and users who do can easily click through and find out about the
different tradeoffs.
On 7/10/2012 5:05 AM, Gregory Maxwell wrote:
> On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi@gmail•com> wrote:
>> What a feature matrix is good at though is it allows you to very quickly
>> find the specific feature or general criteria you're looking for without
>> reading through all of the text. So it might be a useful addition maybe
>> not on Bitcoin.org, but certainly on the wiki.
> I'm generally not a fan of feature matrixes, they encourage "checkbox
> decision making"— which is seldom very good for the decider, though
> it's much loved by the marketing department that puts together the
> matrix. But just becase something is loved by marketing departments
> for its ability to set the agenda in variously biased ways doesn't
> mean its a great thing to emulate.
>
> Take the matrix Luke linked to for example[1]. Now imagine that we
> tunnel MyBitcoin from a year ago and drop it into that table. It
> would have every light green, except 'encryption' (which wouldn't have
> been green for bitcoin-qt then either). It would basically be the
> dominant option by the matrix comparison, and this is without any
> lobbying to get MyBitcoin specific features (like their shopping chart
> interface) added, not to mention the "_vanishes with everyone's
> money_" feature.
>
> I don't think I'm being unreasonable to say that if you could drop in
> something that retrospectively cost people a lot into your decision
> matrix and it comes out on top you're doing something wrong.
>
> In tables like this significant differences like "a remote hacker can
> rob you" get reduced to equal comparison with "chrome spoiler", and
> it further biases development motivations towards features that make
> nice bullets (even if they're seldom used) vs important infrastructure
> which may invisibly improve usage every day or keeps the network
> secure and worth having. "Of course I want the fastest startup! Why
> would I choose anything else?" "What do you mean all my bitcoin is
> gone because the four remaining full nodes were taken over and reorged
> it all?"
>
> I wouldn't expect any really important features which don't have
> complicated compromises attached to them to be omitted from all
> clients for all that long.
>
> Basically matrixes make bad decision making fast, and by making it
> fast it's more attractive than careful decision making that always
> takes time. The text is nice because it contextualizes the complete
> feature set and helps you understand why different clients exist, what
> problems they attempt to solve, and what compromises they make. ...
> without making the unrealistic demand of the user they they know how
> to fairly weigh the value of technical and sometimes subtle issues.
>
>
> [1] https://en.bitcoin.it/wiki/Clients
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Bitcoin-development] Random order for clients page
2012-07-10 9:11 ` Stefan Thomas
@ 2012-07-13 15:20 ` Daniel F
0 siblings, 0 replies; 24+ messages in thread
From: Daniel F @ 2012-07-13 15:20 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]
This discussion is quite bikesheddy, but (or thus? :) ) I will put in my
2c.
The main thing to think about, I think, is "what would be best for the
users". To that end, I suggest the following:
* I do think a page on bitcoin.org listing relatively major, and
relatively vetted, clients is a good idea. Removing it completely and
relegating it to a wiki page, which is likely to contain all sorts of
marginal crufty clients, would likely be a disservice to the users.
* Randomized order is likely also a disservice to the users. We should
list clients in order of "goodness", as determined by whoever(s) we
decide to put in charge of the page. This "goodness" should likely to be
some kind of weighted average of features, security, goodness for
bitcoin network, etc. [1]
** If randomized order is after all chosen, it should be done in
javascript client-side, rather than doing daily page reorgs. If people
without JS don't see random, it's not material at all.
* Prose vs. feature matrix: both have their good and bad points, as
discussed upthread. I think the users will be best served by a
combination of both:
** Prose descriptions of clients should deliberately include negative
points, not just let the user infer them by lack of corresponding
positive mention. (e.g. "This client has fast startup time. That means
you're completely trusting the server operator with your money.") This
task is left up to the person(s) in charge.
** A feature matrix, with carefully chosen and /well defined/
categories, /in addition to prose/ would likely also be of service to
the users. That could be left to the wiki though. The current wiki
clients page seems to be having a good go at it.[2]
** If we are targeting people who "don't know what they're doing", it
may be a good idea to have a 'decision assistant' type setup, where
users are asked several questions and are recommended clients based on
these answers. (This could be done in a static way by having a matrix of
questions.)
Finally - I'd say we're spending disproportionate developer resources on
this question, and if it were completely up to me, I'd resolve this
situation in the following quick-and-painless way: leave page as is, add
negative points to prose, link to wiki clients list. Estimated time to
completion: 1 hour (to think through which negative points to add).
[1] Meehl, 1954, clinical versus statistical prediction... (see also
Grove and Meehl, 1996; Sawyer, 1966) (and yes, despite the age of some
of this research, the conclusions have been surprisingly robust and
timeproof.)
[2] https://en.bitcoin.it/w/index.php?title=Clients&oldid=28615
-nanotube
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2012-07-13 15:21 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-09 15:54 [Bitcoin-development] Random order for clients page Amir Taaki
2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 16:09 ` Amir Taaki
2012-07-09 16:39 ` Stefan Thomas
2012-07-09 16:55 ` Harald Schilly
2012-07-09 17:21 ` Luke-Jr
2012-07-09 17:46 ` Gregory Maxwell
2012-07-09 18:03 ` Alan Reiner
2012-07-09 18:29 ` thomasV1
2012-07-09 18:18 ` Amir Taaki
2012-07-09 18:30 ` Mike Hearn
2012-07-09 22:26 ` Stefan Thomas
2012-07-09 22:37 ` Mike Hearn
2012-07-10 2:36 ` Stefan Thomas
2012-07-10 2:44 ` Alan Reiner
2012-07-10 3:05 ` Gregory Maxwell
2012-07-10 7:12 ` Wladimir
2012-07-10 9:11 ` Stefan Thomas
2012-07-13 15:20 ` Daniel F
2012-07-09 23:07 ` [Bitcoin-development] Wiki client list (was: Random order for clients page) Luke-Jr
2012-07-09 18:48 ` [Bitcoin-development] Random order for clients page Gregory Maxwell
2012-07-09 20:44 ` Jeff Garzik
2012-07-09 17:33 ` Nils Schneider
2012-07-09 18:24 ` Amir Taaki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox