Pages:
Author

Topic: Extending the Payment Protocol with vCards (Read 9664 times)

sr. member
Activity: 378
Merit: 325
hivewallet.com
November 17, 2013, 04:44:17 PM
#22
There seems to be more irrelevant bickering going on here than is really necessary. Taylor, maybe you should just create a BIP on the wiki and go from there?
legendary
Activity: 4690
Merit: 1276
November 17, 2013, 03:35:45 PM
#21
Hmm, do we need a document somewhere (on bitcoin.org?) that clears this up? The Foundation pays Gavin, but that doesn't mean it controls development or tells him what to do. His mission from the Foundation can be summed up as, "carry on doing that thing you do".
...

I don't doubt that what Gavin does is NOT directed by the BF.  But I also don't doubt that the BF pays Gavin because he does pretty much what they desire.

Put another way, it would be a bit naive to believe that the goals of the BF's higher paying members and the work that Gavin performs in shaping the direction of the project are not somewhat aligned.  It seems foolish to believe that the relationship would persist if that were not the case.

To this end, we can expect that Bitcoin evolves in some approximation of the direction that the higher tier members of the Bitcoin Foundation desire.

legendary
Activity: 1526
Merit: 1134
November 17, 2013, 02:01:34 PM
#20
Hmm, do we need a document somewhere (on bitcoin.org?) that clears this up? The Foundation pays Gavin, but that doesn't mean it controls development or tells him what to do. His mission from the Foundation can be summed up as, "carry on doing that thing you do".

So you don't need any blessing. For a payment protocol extension, all you need to do is grab some numbers from the extensions wiki page. Then go ahead and write code (for any wallet you want). There's really no process or bureaucracy here.
full member
Activity: 142
Merit: 100
Hive/Ethereum
November 14, 2013, 05:46:32 PM
#19
You realise the foundation only pays Gavin, right? It's not like there's an army of people waiting for people to suggest features. As you aren't writing code yourself, what possible answer can anyone give you beyond, "wait got someone else to do that".

On the contrary, I am a developer--hence the request-for-comment.

So I'll ask again: "What can developers work on that will have the almighty blessing of the Foundation?"
legendary
Activity: 1526
Merit: 1134
November 14, 2013, 01:44:01 PM
#18
You realise the foundation only pays Gavin, right? It's not like there's an army of people waiting for people to suggest features. As you aren't writing code yourself, what possible answer can anyone give you beyond, "wait got someone else to do that".
full member
Activity: 142
Merit: 100
Hive/Ethereum
November 14, 2013, 01:02:40 PM
#17
No, not at all. Good standards always start with the code first, and the spec second. If you don't do an implementation then you invariably encounter some detail whilst writing the code that you had previously overlooked, or find ways to do things in an easier way, and then you want to change the spec. Also, having an implementation makes it easy for other developers to test their code against yours so they can check it's compatible.

The payment protocol itself was done this way. We prototyped some ideas in code, and once the implementation was largely finished, it became a BIP.

Mike, respectfully (or not--I don't seem to be getting any), no matter the topic, all I hear is "wait".

* Need a refund address? Wait for Payment Protocol.
* Want to discuss contact exchange? Wait for Payment Protocol Android implementation.
* Want an answer to "redlisting"? Wait for the Foundation to publish an official position.
* Payment Protocol secured by PGP instead of PKI? Thread locked.

I'm starting to question what value the Bitcoin Foundation provides for the community if they're just going to ignore our requests to implement specific things. i.e. How long have we been waiting for spendfrom/coincontrol in QT? The Foundation pays developers to work on "important" features, but if those features deviate too far from what the core community wants, they're going to paint themselves into a corner and have no users left at all.

Since I apparently need a Official Membership Stamp of Approval(tm) from the Bitcoin Foundation before speaking up, what can us feeble-minded developers work on that will have the almighty blessing of the Foundation? i.e. Where are its priorities? Since Foundation forums are locked from non-members, I'd really love to know.
legendary
Activity: 1526
Merit: 1134
November 13, 2013, 03:22:55 PM
#16
No, not at all. Good standards always start with the code first, and the spec second. If you don't do an implementation then you invariably encounter some detail whilst writing the code that you had previously overlooked, or find ways to do things in an easier way, and then you want to change the spec. Also, having an implementation makes it easy for other developers to test their code against yours so they can check it's compatible.

The payment protocol itself was done this way. We prototyped some ideas in code, and once the implementation was largely finished, it became a BIP.
full member
Activity: 142
Merit: 100
Hive/Ethereum
November 13, 2013, 03:06:03 PM
#15
Sure, we're all in violent agreement that there's a UX problem to solve. The question is just a matter of how to solve it. And actually there's no reason that we can't have multiple solutions at once.

To make progress here, what I suggest is that you wait a little bit until the payment protocol is implemented in the Android wallet app, and then prototype adding it to that (as I guess, person to person payments are often mobile). Once it's working and people agree that it's good, you could turn it into a BIP.

Wait, so you're suggesting we code first THEN write the spec? Seems a bit backwards, no?

I don't understand the objection to discussing how to exchange contact information in a standard format. Perhaps no one else sees this as being a problem since there's only three people on this thread. Would love to see other developers comment on this idea... unless they've already given up on the Payment Protocol as a solution for users?
legendary
Activity: 1526
Merit: 1134
November 13, 2013, 05:30:40 AM
#14
Sure, we're all in violent agreement that there's a UX problem to solve. The question is just a matter of how to solve it. And actually there's no reason that we can't have multiple solutions at once.

To make progress here, what I suggest is that you wait a little bit until the payment protocol is implemented in the Android wallet app, and then prototype adding it to that (as I guess, person to person payments are often mobile). Once it's working and people agree that it's good, you could turn it into a BIP.
sr. member
Activity: 378
Merit: 325
hivewallet.com
November 12, 2013, 03:00:18 PM
#13
You've got to admit, it's a terrible user experience. By having standardized contact data embeddable, we could transfer a name/photo/something to provide a better UX. After all, the Foundation is pushing for one-time-use addresses, so the label/address association goes out the window.

+1000
full member
Activity: 142
Merit: 100
Hive/Ethereum
November 12, 2013, 01:34:40 PM
#12
It's very rare for someone to pay someone else with no idea at all of who that person is. Even on black markets, you know you're paying some specific identity (it just happens to not be their legal identity). But for most payments you do know who you are paying. Bitcoin strives to ensure other people don't know who you are paying, but it doesn't require that you yourself don't know.

Outside of the context of illegal transactions, it's typically A-OK if someone requests payment and their name/photo shows up in your wallet. Indeed it's helpful so you can remember what a transaction was about.

I've sent money to friends for various things (experience Bitcoin, payment for beers, etc.), and while they know who I am, all they see is a transaction received on 1ThisIsARandomAddress.

You've got to admit, it's a terrible user experience. By having standardized contact data embeddable, we could transfer a name/photo/something to provide a better UX. After all, the Foundation is pushing for one-time-use addresses, so the label/address association goes out the window.

Mike, if we're all out to lunch with intent of splitting the bill equally and you receive 4 payments in equal amounts. How do you know whose refund address is whose? A crappy certificate name?
sr. member
Activity: 378
Merit: 325
hivewallet.com
November 12, 2013, 01:24:06 PM
#11
It's very rare for someone to pay someone else with no idea at all of who that person is. Even on black markets, you know you're paying some specific identity (it just happens to not be their legal identity). But for most payments you do know who you are paying. Bitcoin strives to ensure other people don't know who you are paying, but it doesn't require that you yourself don't know.

Outside of the context of illegal transactions, it's typically A-OK if someone requests payment and their name/photo shows up in your wallet. Indeed it's helpful so you can remember what a transaction was about.

They may know who that person is, but we're talking about a matter of convenience. If (some address) sends me money, I would greatly prefer that a packet of data that can pre-populate my contact list be included. Otherwise I might spend 3 minutes fiddling with it to add such data, if I ever do at all. It's as simple a need as that. Perhaps a small UX tweak, but from my view a substantially time-saving and helpful one.
legendary
Activity: 1526
Merit: 1134
November 12, 2013, 10:40:17 AM
#10
It's very rare for someone to pay someone else with no idea at all of who that person is. Even on black markets, you know you're paying some specific identity (it just happens to not be their legal identity). But for most payments you do know who you are paying. Bitcoin strives to ensure other people don't know who you are paying, but it doesn't require that you yourself don't know.

Outside of the context of illegal transactions, it's typically A-OK if someone requests payment and their name/photo shows up in your wallet. Indeed it's helpful so you can remember what a transaction was about.
full member
Activity: 142
Merit: 100
Hive/Ethereum
November 12, 2013, 09:55:29 AM
#9
I don't want to come across as dismissive. If someone wants to build a P2P social network, and integrate it with Bitcoin, that's great - more power to them.

It depends what your goal is. If your goal is "build a p2p social network with payments functionality", it's the right approach. If your goal is "make Bitcoin more usable" it's the wrong approach (currently).

Not sure on this inherent need for a "social network". Plenty of people use the internet without Facebook/Twitter/etc. I think the idea to be able to integrate these and Bitcoin is a fine idea, but I don't see it as an absolute requirement in a world of pseudonymity.
legendary
Activity: 1526
Merit: 1134
November 12, 2013, 07:11:30 AM
#8
I don't want to come across as dismissive. If someone wants to build a P2P social network, and integrate it with Bitcoin, that's great - more power to them.

It depends what your goal is. If your goal is "build a p2p social network with payments functionality", it's the right approach. If your goal is "make Bitcoin more usable" it's the wrong approach (currently).
sr. member
Activity: 378
Merit: 325
hivewallet.com
November 11, 2013, 04:25:14 PM
#7
Don't get me wrong, I would love to see fully decentralised P2P infrastructure for everything. But creating just one of these infrastructures and making it competitive is an absolutely massive piece of work. Trying to do everything at once is trying to boil the ocean.

If someone were to create a usable, appealing P2P/distributed social network and it took off, by all means, go ahead and integrate it with the payment protocol ... but features that nobody is going to use due to the unpopularity of the underlying integrated system have a real cost.

Let's say that Bitcoin wallets are presently in the hands of less than .01% of the world's population. That implies that there are ages and ages of massive research and development ahead of us... So why dismiss this kind of an idea now? Other than what we may ambitiously plan, we don't know what is coming. Besides, aren't we talking about bootstrapping on top of the payment protocol itself?
legendary
Activity: 1526
Merit: 1134
November 11, 2013, 06:54:06 AM
#6
Don't get me wrong, I would love to see fully decentralised P2P infrastructure for everything. But creating just one of these infrastructures and making it competitive is an absolutely massive piece of work. Trying to do everything at once is trying to boil the ocean.

If someone were to create a usable, appealing P2P/distributed social network and it took off, by all means, go ahead and integrate it with the payment protocol ... but features that nobody is going to use due to the unpopularity of the underlying integrated system have a real cost.
full member
Activity: 142
Merit: 100
Hive/Ethereum
November 10, 2013, 01:06:15 PM
#5
Little by little I see your idea extending towards this: https://www.youtube.com/watch?v=IVFBwDHWxG0

+1

Anything that allows us operate our own clouds instead of relying on third-party solution is an improvement. I posted this thread's topic to the dev mailing list and Mike Hearn responded suggesting we rely on social network APIs, but I don't see how relying on yet another party improves Bitcoin whatsoever.

Maybe this should lend some context:

Quote from: Satoshi
What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.
sr. member
Activity: 378
Merit: 325
hivewallet.com
November 09, 2013, 01:27:10 PM
#4
Little by little I see your idea extending towards this: https://www.youtube.com/watch?v=IVFBwDHWxG0

I think you've got the idea, indeed.
full member
Activity: 221
Merit: 100
November 09, 2013, 01:20:35 PM
#3
Little by little I see your idea extending towards this: https://www.youtube.com/watch?v=IVFBwDHWxG0
Pages:
Jump to: