[Forgive the cross-post...]
Finally, we've arrived! Thanks to the many of you who generously contributed. An especially big shout out to Paul Jones for his passion and dedication, who as editor had the unenviable job of trying to appease everyone.
--
---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I look forward to seeing how this technology is deployed including outside of the OpenID use case.
My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.
It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have. I like to keep long lived identifiers for systems I build, so there's a degree of guess work there. Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.
It's great finally to have a solution that gives us meta data from an email address, I think this has been a missing piece of the web for some time!
Melvin,I look forward to seeing how this technology is deployed including outside of the OpenID use case.Me, too. There are plenty of use cases and I have some expectations for WebFinger that I hope do result in product features. During the weekend, I thought that using WebFinger as a means of sending Bitcoins would be very cool. See: http://www.packetizer.com/people/paulej/blog/53
http://bitcoin.org/rel/address
My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.I do hope that you do not introduce a lot of stuff that substantially changes the JRD. I'm not sure what more advanced things you want to do, but if you have a need for a lot of different data members, it might be better to refer to another document.
It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have. I like to keep long lived identifiers for systems I build, so there's a degree of guess work there. Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.It will take time for WebFinger to gain widespread use, but I would strongly encourage use of "acct" from the outset. Using "mailto" is certainly possible, but if the objective is to identify a user's account and we cannot reach agreement on what the account identifier is, that's a problem. What would be the reason for using the "mailto" scheme when referring to a user account? Now, if you really want information about the email address, the "mailto" might be appropriate.
It's great finally to have a solution that gives us meta data from an email address, I think this has been a missing piece of the web for some time!Agreed. This is one more piece to building a programmable web and making the Internet that much more useful.Paul
--
On 2 October 2013 17:10, Paul E. Jones <pau...@packetizer.com> wrote:
Melvin,I look forward to seeing how this technology is deployed including outside of the OpenID use case.Me, too. There are plenty of use cases and I have some expectations for WebFinger that I hope do result in product features. During the weekend, I thought that using WebFinger as a means of sending Bitcoins would be very cool. See: http://www.packetizer.com/people/paulej/blog/53Nice idea, howeverhttp://bitcoin.org/rel/address
Doesnt seem to dereference.
My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.I do hope that you do not introduce a lot of stuff that substantially changes the JRD. I'm not sure what more advanced things you want to do, but if you have a need for a lot of different data members, it might be better to refer to another document.My main interests are the social web and payments. JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations. For example, unordered lists of links (e.g. friends). Also for finance I tend to use numbers in transactions, and JRD can only handle strings. I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.
It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have. I like to keep long lived identifiers for systems I build, so there's a degree of guess work there. Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.It will take time for WebFinger to gain widespread use, but I would strongly encourage use of "acct" from the outset. Using "mailto" is certainly possible, but if the objective is to identify a user's account and we cannot reach agreement on what the account identifier is, that's a problem. What would be the reason for using the "mailto" scheme when referring to a user account? Now, if you really want information about the email address, the "mailto" might be appropriate.There's no consensus on which string is a primary key for identity (unfortunately) on the net today. Some prefer http profiles, some prefer email addresses, some prefer public keys, some prefer acct: URIs, and perhaps in future telephone number will become more popular. acct: will take some time to pick up. My use case for webfinger is to add meta data to email type addresses, so mailto is a well deployed candidate for that. On the client side, I'll probably be handling acct: too. If acct: really takes off I can spend more time handling that type of identifier, but we'll only know given time.
Melvin,On 2 October 2013 17:10, Paul E. Jones <pau...@packetizer.com> wrote:
Melvin,I look forward to seeing how this technology is deployed including outside of the OpenID use case.Me, too. There are plenty of use cases and I have some expectations for WebFinger that I hope do result in product features. During the weekend, I thought that using WebFinger as a means of sending Bitcoins would be very cool. See: http://www.packetizer.com/people/paulej/blog/53Nice idea, howeverhttp://bitcoin.org/rel/address
Doesnt seem to dereference.I just made that up. It's only to demonstrate the possibility. I also made up the "payments" link relation values, too. The idea with the payments link relation is that the URL there would point to a location where a client would query with HTTP to get the payment address. These would not necessarily even have to be two link relation types, since the client could see one is an HTTP href and dereference it. In any case, I threw this out there for people to chew on. I don't think folks in the Bitcoin community have really taken a good look at this. WebFinger really has to get deployed first. It's also not a priority, since Bitcoin users are happy with using QR codes and copying and pasting those long 35 character Bitcoin addresses. The average user isn't going to like that, though, so they do need something a little more user friendly.
My thoughts currently are that JRD seems great for many use cases, but for some advanced use cases (for me im interested in social and commerce) I may use a different type of JSON depending on the need, the spec allows this which is great.I do hope that you do not introduce a lot of stuff that substantially changes the JRD. I'm not sure what more advanced things you want to do, but if you have a need for a lot of different data members, it might be better to refer to another document.My main interests are the social web and payments. JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations. For example, unordered lists of links (e.g. friends). Also for finance I tend to use numbers in transactions, and JRD can only handle strings. I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.For those things, though, why would they be in WebFinger itself? For example, if you wish to have a list of friends, it would seem that WF would be useful to discover the location of the friend list, but the friend list itself would be in whatever format is most suitable.
It will take time to see if acct: catches on as a global pattern in the same way that http: and mailto: have. I like to keep long lived identifiers for systems I build, so there's a degree of guess work there. Personally I'm going to stick to mailto: but watch and see if acct: catches on, then think about switching.It will take time for WebFinger to gain widespread use, but I would strongly encourage use of "acct" from the outset. Using "mailto" is certainly possible, but if the objective is to identify a user's account and we cannot reach agreement on what the account identifier is, that's a problem. What would be the reason for using the "mailto" scheme when referring to a user account? Now, if you really want information about the email address, the "mailto" might be appropriate.There's no consensus on which string is a primary key for identity (unfortunately) on the net today. Some prefer http profiles, some prefer email addresses, some prefer public keys, some prefer acct: URIs, and perhaps in future telephone number will become more popular. acct: will take some time to pick up. My use case for webfinger is to add meta data to email type addresses, so mailto is a well deployed candidate for that. On the client side, I'll probably be handling acct: too. If acct: really takes off I can spend more time handling that type of identifier, but we'll only know given time.It was this very reason that "acct" grew legs and became its own thing. There was a desire to have something that was familiar to people and easily understood, but it's not an email address. The "mailto" URI also has a whole lot of baggage that goes with it that makes it just that much more complicated. For example, one can include a subject line, multiple "to" addresses, etc. So, what does WF do with "mailto:pau...@packetizer.com,j...@example.com?subject=Now%20What?" This scheme can be cranky. Plus, you need something for social networks and there people have accounts. The acct URI is a really good fit, because it has the familiar look of the email address and would should really be equated by the human user as the same identifier. It's just the WF client and server that look at the URI scheme.
I just made that up. It's only to demonstrate the possibility. I also made up the "payments" link relation values, too. The idea with the payments link relation is that the URL there would point to a location where a client would query with HTTP to get the payment address. These would not necessarily even have to be two link relation types, since the client could see one is an HTTP href and dereference it. In any case, I threw this out there for people to chew on. I don't think folks in the Bitcoin community have really taken a good look at this. WebFinger really has to get deployed first. It's also not a priority, since Bitcoin users are happy with using QR codes and copying and pasting those long 35 character Bitcoin addresses. The average user isn't going to like that, though, so they do need something a little more user friendly.Got it.Normally it's something of a best practice to put a bunch of terms in a single document so that you only have at dereference it once to find out all the meanings.
As it happens, I should be the person maintaining the bitcoin schema, so I could add something like this upstream :)
My main interests are the social web and payments. JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations. For example, unordered lists of links (e.g. friends). Also for finance I tend to use numbers in transactions, and JRD can only handle strings. I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.For those things, though, why would they be in WebFinger itself? For example, if you wish to have a list of friends, it would seem that WF would be useful to discover the location of the friend list, but the friend list itself would be in whatever format is most suitable.You can do that too, but it's one extra round trip, is the only thing.
It was this very reason that "acct" grew legs and became its own thing. There was a desire to have something that was familiar to people and easily understood, but it's not an email address. The "mailto" URI also has a whole lot of baggage that goes with it that makes it just that much more complicated. For example, one can include a subject line, multiple "to" addresses, etc. So, what does WF do with "mailto:pau...@packetizer.com,j...@example.com?subject=Now%20What?" This scheme can be cranky. Plus, you need something for social networks and there people have accounts. The acct URI is a really good fit, because it has the familiar look of the email address and would should really be equated by the human user as the same identifier. It's just the WF client and server that look at the URI scheme.Sure, I get this. But the original use case of webfinger (about 5 years ago) was to get meta data about email. That it can do accounts too is great, it's just that as a relatively new URI scheme, you often need a bit of time to see how heavily deployed it gets.
Melvin,I just made that up. It's only to demonstrate the possibility. I also made up the "payments" link relation values, too. The idea with the payments link relation is that the URL there would point to a location where a client would query with HTTP to get the payment address. These would not necessarily even have to be two link relation types, since the client could see one is an HTTP href and dereference it. In any case, I threw this out there for people to chew on. I don't think folks in the Bitcoin community have really taken a good look at this. WebFinger really has to get deployed first. It's also not a priority, since Bitcoin users are happy with using QR codes and copying and pasting those long 35 character Bitcoin addresses. The average user isn't going to like that, though, so they do need something a little more user friendly.Got it.Normally it's something of a best practice to put a bunch of terms in a single document so that you only have at dereference it once to find out all the meanings.
As it happens, I should be the person maintaining the bitcoin schema, so I could add something like this upstream :)Wow, that would be awesome! I think the idea behind Bitcoin is good, as it has the potential for simplifying the payment process (especially online) and removes the risks merchants face every time they accept a credit card. The only "ugly" part of using Bitcoin, IMO, is the complex addressing scheme. For me and you, it's not a big deal, but it's not all all intuitive to the average person.
My main interests are the social web and payments. JRD is great for a lot of use cases but there are some things it cant handle as easily as other serializations. For example, unordered lists of links (e.g. friends). Also for finance I tend to use numbers in transactions, and JRD can only handle strings. I dont expect JRD to change notably, so there would perhaps be other ways to handle such cases.For those things, though, why would they be in WebFinger itself? For example, if you wish to have a list of friends, it would seem that WF would be useful to discover the location of the friend list, but the friend list itself would be in whatever format is most suitable.You can do that too, but it's one extra round trip, is the only thing.That's true, but trying to put a significant amount of data into a WF response can introduce problems of its own. If every application (e.g., vcard) was inserted into WebFinger, the JRD would be enormous.It was this very reason that "acct" grew legs and became its own thing. There was a desire to have something that was familiar to people and easily understood, but it's not an email address. The "mailto" URI also has a whole lot of baggage that goes with it that makes it just that much more complicated. For example, one can include a subject line, multiple "to" addresses, etc. So, what does WF do with "mailto:pau...@packetizer.com,j...@example.com?subject=Now%20What?" This scheme can be cranky. Plus, you need something for social networks and there people have accounts. The acct URI is a really good fit, because it has the familiar look of the email address and would should really be equated by the human user as the same identifier. It's just the WF client and server that look at the URI scheme.Sure, I get this. But the original use case of webfinger (about 5 years ago) was to get meta data about email. That it can do accounts too is great, it's just that as a relatively new URI scheme, you often need a bit of time to see how heavily deployed it gets.You're correct about the history, however using email: with WF is also a new deployment; it's re-purposing the schema for use in a different application. There's nothing wrong with that, but it's not the most ideal solution, IMO. Given that RFC 7033 is brand new and any implementations would be relatively new, I'd really like to encourage use of acct from the outset so we don't have to deal with interoperability issues where some opted to use mailto: and some opted to use acct: to refer to WF information about a human user. Let's get started on the right foot :-)Paul
--
Melvin,
To advertise a Bitcoin address or payment URL, we need to define a link relation type. Are you defining "bitcoin" to be that link relation or is it https://cc.rww.io/vocab#bitcoin? I didn't see anything on either of those links that would have provided me with a hint that ether is the "link relation type" to use in either a web page or WebFinger.
|
Paul
On 10/11/2013 11:33 AM, Melvin Carvalho wrote:
Wow, that would be awesome! I think the idea behind Bitcoin is good, as it has the potential for simplifying the payment process (especially online) and removes the risks merchants face every time they accept a credit card. The only "ugly" part of using Bitcoin, IMO, is the complex addressing scheme. For me and you, it's not a big deal, but it's not all all intuitive to the average person.
Done!
You can use the following link to indicate a bitcoin address. I'm working with the bitcoin community to add other currencies (e.g. litecoin, ppcoin) shortly
On 11 October 2013 20:06, Paul E. Jones <pau...@packetizer.com> wrote:
Melvin,
To advertise a Bitcoin address or payment URL, we need to define a link relation type. Are you defining "bitcoin" to be that link relation or is it https://cc.rww.io/vocab#bitcoin? I didn't see anything on either of those links that would have provided me with a hint that ether is the "link relation type" to use in either a web page or WebFinger.
Melvin,From reading the web page, I never would have guessed this URI. I think it would be beneficial if the web page actually provided the fully-qualified URI.
On 10/11/2013 3:09 PM, Melvin Carvalho wrote:
On 11 October 2013 20:06, Paul E. Jones <pau...@packetizer.com> wrote:
Melvin,
To advertise a Bitcoin address or payment URL, we need to define a link relation type. Are you defining "bitcoin" to be that link relation or is it https://cc.rww.io/vocab#bitcoin? I didn't see anything on either of those links that would have provided me with a hint that ether is the "link relation type" to use in either a web page or WebFinger.
As for the particular URI to use, what I had suggested was http://bitcoin.org/rel/address. The reason for that suggestion is that the domain is owned by the Bitcoin Foundation. Since I'm not a core person in the Bitcoin community, I obviously cannot speak for them. But, it makes sense to me that the identifier should be officially accepted. Have you reached out to them?
Paul
From reading the web page, I never would have guessed this URI. I think it would be beneficial if the web page actually provided the fully-qualified URI.
Sure, I only put this together in the last day after you requested, documentation is in progress.
Im unsure what you mean by fully qualified URI.