_hc: mvdan what do you think about including the fingerprint in the DB?
_hc that would make it much easier to add repos that include the fingerprint in the URL
_hc fingerprint == fingerprint of DB.pubkey
CiaranG: _hc How would it have the pubkey already in the database?
mvdan Sure, though remember to bump the dbvercode and update the repo database
CiaranG Or am I misunderstanding?
mvdan (I meant table)
_hc: CiaranG it wouldn't yet
_hc so when it first makes the socket connection and gets the pubkey, then it would have to compare the store fingerprint
_hc but it would have the pubkey and fingerprint if the repo already existed in FDroid
_hc client
CiaranG Oh, ok, that makes sense
_hc then when we have an incoming repo that includes a fingerprint, it can easily compare both the URL and the fingerprint to what's stored in teh DB
CiaranG So it's just a temporary storage of it until it gets the actual public key
_hc I suppose
_hc it wouldn't really be temporary since it would be used for comparisons whenever there was an incoming repo
CiaranG It's not tied to a particular repo?
_hc otherwise the Add Repo UI will have to make a socket connection to get the pubkey
_hc it would definitely be tied to a certain repo
CiaranG Right
CiaranG So what I'm saying is that you have your incoming url+fingerprint
_hc it would be one of the standard bits of data stored about a repo
CiaranG But once you've actually connected to that repo during an update, you get the real pubkey
_hc exactly
CiaranG At which point, the fingerprint is never needed again
_hc it would be needed the next time someone adds a repo with a fingerprint, since that's how AddRepo checks to see if the repo already exists
CiaranG Why does it check the fingerprint, and not the url?
_hc it would check both
_hc but actually, we're planning on implementing bluetooth and OTRDATA methods for contacting repos, in which case, the pubkey becomes more of the identifier of a given repo
CiaranG aha
CiaranG So that's why
_hc now that I think about it, the fingerprint could be removed from the database once the pubkey is downloaded since the fingerprint can be caluclated from the pubkey
CiaranG But that means a) you can't have an unsigned repo? and b) you can't have two repos signed with the same key?
_hc hopefully we can still support both
_hc I think we cna
_hc but yeah, that's something to think about
CiaranG I was about to say I don't think b) is a problem - I was only raising it because it's a restriction that's never existed before
CiaranG But actually it is a problem
CiaranG f-droid.org/repo - f-droid.org/archive
CiaranG Two repos, same pubkey
_hc for /repo and /archive?
_hc hehe
_hc yes, something to think about
_hc in the meantime, I'm proposing just adding the fingerprint to work with HTTPS URLs
_hc we're still working out how to handle bluetooth and OTRDATA
_hc we have a working prototype of the p2p HTTPS repos
CiaranG Seems to me they could still have a unique 'url'
CiaranG Even if it's not a real url
_hc yeah, that's one possibilitiy
_hc I think that works with bluetooth since there is some kind of unique id that represents the device
_hc the tricky one is local wifi
_hc and with OTRDATA we should be able to use the name of the XMPP account of the other device in the URL
_hc with local wifi, it'll share the same URL and code as the static HTTPS servers, but will be changing a lot
_hc URL-style
_hc I suppose we could make up a fake hostname based on a unique id of the phone
_hc something like a hash of the devicename and Android ID