
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Service discovery is an interesting problem, but it's one we can kick down the road for now until we start having concrete, optional services attached to FxA that we need to manage on behalf of the user.</div></div></blockquote><div><br></div><div>I think that road ends just about now: the can is bouncing off a wall.</div><div><br></div><div>We want to be building a replacement for Send Tab, a remote backend for reading list, and a bunch of other roadmapped stuff that we can launch this year and next… not to mention a replacement for Sync, bit by bit.</div><div><br></div><div>Attaching services to your identity is, IMO, the first non-quality-related task that needs to be addressed. We are blocked on shipping FxA-attached services until that's done.</div><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I don't consider the profile service to be something we necessarily need to discover. The scope of our initial profile effort should assume that e.g., <a href="http://profile.accounts.firefox.com/">profile.accounts.firefox.com</a> is a well known service for serving profile data associated with your FxA. </div></div></blockquote><br></div><div>If we're hard-linking that to an account server, why not discover that URL from a .well-known on the account server, or just have the account server domain do it?</div><div><br></div><div>(It can't just be hard-coded to <a href="http://profile.accounts.firefox.com">profile.accounts.firefox.com</a>, or we're going to hit dev/stage and self-host problems, so maybe that's what you mean.)</div></body></html>