Nov 21st IRC log about identifying repos

_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 -

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