[Bitcoin-development] Bitcoin Wallet for Android
Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. Otherwise, we should make a separate section for non-opensource 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
Sources are available here: http://code.google.com/p/bitcoin-wallet/ Mats Quoting Amir Taaki zgen...@yahoo.com: Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. Otherwise, we should make a separate section for non-opensource 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 -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
OK thanks. I just went and made those sections then saw your posts. Anyway we have a section for proprietary clients now. Please tell me if anything looks disagreeable, http://bitcoin.org/clients.html One thing I'm going to do is randomise the positioning order within sections upon refresh. - Original Message - From: m...@henricson.se m...@henricson.se To: bitcoin-development@lists.sourceforge.net Cc: Sent: Monday, July 9, 2012 11:19 AM Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android Sources are available here: http://code.google.com/p/bitcoin-wallet/ Mats Quoting Amir Taaki zgen...@yahoo.com: Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. Otherwise, we should make a separate section for non-opensource 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 -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 7:34 AM, Jorge Timón timon.elvi...@gmail.com wrote: Didn't even know that they were proprietary software bitcoin clients. Should people trust them? Should the web promote them? After all, you can't know what they do. What if one of them contains a back door or something? I would say it's better not risk to apologize later. I agree too. Not that being open is _any_ guarantee, ideally we'd want standards of review and testing, but thats a bit much to ask for right now. -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell gmaxw...@gmail.com wrote: I've reverted these additions to the page, nothing personal but— Er, to be clear, I left the android software in because the source is available (And I'm told its had some review). I removed the proprietary software section the plug for the blockchain.info webservices, and the demotion of the armory client. As far as criteria goes, I don't think we should list anything with a security model weaker than SPV unless users can practically operate their own servers. …and even that I'm a little uneasy with, because most people will use the defaults. Ideally even thin clients would have a near SPV security model, just without the bandwidth. But since the alternative for thin clients is centralized web services the lower standard will probably have better net results for now. Nor do I think we should list anything which can't currently be subjected to independent review of the whole stack (e.g. including the server components in thinclients, unless the server is untrusted). In the future this should be raised to there existing actual evidence of third party review. -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
Any chance the blockchain.info iphone app could be included on the clients page? The source is available under an lGPL license: https://github.com/blockchain/My-Wallet-iPhone. More info:https://blockchain.info/wallet/iphone-app Also the javascript web front end can be reviewed using a combination of https://github.com/blockchain/My-Wallet and https://github.com/blockchain/My-Wallet-Integrity-Checker but I could see why that might be more of an issue for the the official site. Thank You, Ben Reeves On 9 Jul 2012, at 15:00, Gregory Maxwell wrote: On Mon, Jul 9, 2012 at 5:21 AM, Amir Taaki zgen...@yahoo.com wrote: Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. I've reverted these additions to the page, nothing personal but— At the moment I'm strongly opposed to including any non-reviewable client options (including centrally operated web services) on the page, and I think this need to be discussed along with establishing requirements. -- 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
Re: [Bitcoin-development] Random order for clients page
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 gmaxw...@gmail.com To: Amir Taaki zgen...@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 zgen...@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
Re: [Bitcoin-development] Random order for clients page
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 gmaxw...@gmail.com To: Amir Taaki zgen...@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 zgen...@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 -- 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
Re: [Bitcoin-development] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 11:21 AM, Amir Taaki zgen...@yahoo.com wrote: Is the sourcecode for this client available for review? I couldn't find it. yes: http://code.google.com/p/bitcoin-wallet/ and it is built upon http://code.google.com/p/bitcoinj/ harald -- 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
Re: [Bitcoin-development] Random order for clients page
FWIW, all this argumenting is why my original suggestion for a Clients list focussed on objective information in alphabetical order. -- 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
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@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
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 On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@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 -- 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.
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
Re: [Bitcoin-development] Random order for clients page
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 gmaxw...@gmail.com To: Amir Taaki zgen...@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 zgen...@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
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 12:04 PM, Gregory Maxwell gmaxw...@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. jgar...@exmulti.com -- 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
Re: [Bitcoin-development] Random order for clients page
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. -- 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
Re: [Bitcoin-development] Random order for clients page
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 n...@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 -- 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
Re: [Bitcoin-development] Random order for clients page
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. -- 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
