4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-04 23:51:11 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Meeting logs for the week of 2019-07-22 to 28

Browse Source 
+ newline pb solved on i2p meeting
This commit is contained in:
el00ruobuob 2019-07-29 15:37:36 +02:00
parent aa775f1ed6
commit 45832b719e
No known key found for this signature in database
GPG Key ID: 8794A50E11FE51A0
3 changed files with 378 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
_posts/2019-07-22-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-07-22.md Normal file
View File

@ -0,0 +1,121 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-07-22
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** OK, let's get started
**\<sarang>** GREETINGS
**\<suraeNoether>** hello fellow not-robots
**\<sarang>** Let's move on to ROUNDTABLE
**\<sarang>** suraeNoether: care to begin?
**\<suraeNoether>** sure
**\<suraeNoether>** so this weekend i finally posted the konferenco post mortem report, the budget, and markdown'd all the things: https://www.reddit.com/r/Monero/comments/cfsc2m/suraes\_content\_dump\_konferenco\_post\_morto\_budget/
**\<suraeNoether>** this includes my research report for the last quarter and my request for funding for Aug, Sep, Oct.
**\<suraeNoether>** And isthmus pointed out a property of zcash's shielded pool that i am capable of modeling with my matching simulations, so i've spent a few hours this past weekend trying to get those working (still a wip)
**\<suraeNoether>** that's all
**\<suraeNoether>** sarang?
**\<sarang>** Nice!
**\<sarang>** I've posted the handout and some sample code for my upcoming DEF CON workshop
**\<suraeNoether>** nice! thatsafineoutreach.gif
**\<sarang>** (note that you should not use the handout or sample code in production environments, of course... only for playing around)
**\<sarang>** And I have incomplete work on an RCT3 proof of concept implementation
**\<sarang>** with some efficiency improvements
**\<sarang>** the batching opportunities for RCT3 are quite nice
**\<sarang>** as is the fact that the prover and verifier are relatively straightforward
**\<sarang>** also also it can take advantage of any existing rangeproof implementation
**\<sarang>** Any questions on these?
**\<kenshamir[m]>** Hi Sarang, yes
**\<kenshamir[m]>** Do you believe that all of the alternatives; omniring, ringct and lelantus would be a better alternative to the current ringCT even with cLSAG?
**\<kenshamir[m]>** Are you waiting for a feature or an event before choosing a specific alternative?
**\<kenshamir[m]>** better in terms of performance, space savings and anonymity set
**\<sarang>** In terms of practical anonymity set, the sublinear schemes are an improvement at first glance
**\<sarang>** but
**\<sarang>** Lelantus requires a separate output pool and self-spends to avoid tracing
**\<sarang>** Omniring does not support efficient batching
**\<sarang>** RCT3 requires a separate output pool
**\<sarang>** and in all cases, larger anonymity sets require a careful look at handling ring representation, which can become substantial
**\<kenshamir[m]>** Hmm, so is it fair to say that in their infancy, they are not ready to take over the current ringCT?
**\<sarang>** IMO not without a lot of careful thought on implementation details
**\<sarang>** That being said, I'm looking at two particular things regarding that:
**\<kenshamir[m]>** Do you think it would be better to move away from hiding users in a set of users, to hiding coins in a set of coins?
**\<sarang>** One is determining if/how to efficiently split the rangeproof from Omniring for better verification
**\<kenshamir[m]>** Similar to zcash
**\<sarang>** Two is figuring out if it's possible to use the same key image format with RCT3
**\<sarang>** Full anonymity would be great if we could do it efficiently
**\<dEBRUYNE>** And without a trusted setup :P
**\<kenshamir[m]>** > Two is figuring out if it's possible to use the same key image format with RCT3
**\<kenshamir[m]>** This is very interesting
**\<suraeNoether>** "Do you think it would be better to move away from hiding users in a set of users, to hiding coins in a set of coins?" \<-- what's the difference?
**\<suraeNoether>** at a KYC exchange, the exchange knows your personal details and which coins are yours. same same as far as the most common threat model is concerned... unless i'm missing something
**\<sarang>** Oh I totally missed that distinction in what kenshamir[m] said
**\<sarang>** In all cases, users are used to derive coin data
**\<sarang>** Anon sets are considered by coins, not by users
**\<sarang>** Does that answer your question kenshamir[m] ?
**\<kenshamir[m]>** Yep, I was re-reading it to make sure I understood
**\<kenshamir[m]>** \<dEBRUYNE "And without a trusted setup :P"> yes this too :)
**\<sarang>** This actually leads neatly into my ACTION ITEMS
**\<sarang>** I'm working on including proper batch verification in the proof of concept code, and integrating into the test transaction flows
**\<sarang>** Then I want to dive more deeply into the two things I mentioned to kenshamir[m]
**\<sarang>** 1. splitting Omniring proofs for better batching
**\<sarang>** 2. determining the feasibility/security of retaining key image structure in RCT3 to avoid an output pool split
**\<sarang>** And finalizing DEF CON material, of course
**\<sarang>** I'll be giving a talk and leading a workshop in the Monero village, as well as staffing an information table
**\<sarang>** and also doing a panel discussion in the blockchain village
**\<sarang>** suraeNoether: your action items?
**\<suraeNoether>** uhm just working on sims
**\<suraeNoether>** i want to finish the matching stuff soonish to start answering questions rigorously
**\<suraeNoether>** and i want to catch up on your work on the Big Three Trustless Protocols, which is what i'm calling them in my head
**\<sarang>** Yes, IMO the matching stuff is a priority in terms of getting results
**\<sarang>** Moving back in the agenda slightly, does anyone else have either research to present or general questions to ask?
**\<kenshamir[m]>** What was the matching stuff, you guys are referring to?
**\<sarang>** Treating possible spend histories in the tx graph as a graph matching problem
**\<sarang>** and analyzing the structure and complexity
**\<sarang>** In an ideal tx graph, the number of valid matchings (under any data you might already have) should be very high, to provide useful anonymity
**\<kenshamir[m]>** \<sarang "Treating possible spend historie"> ohh right, this is very cool research
**\<sarang>** It's one possible metric to examine anonymity
**\<sarang>** (but certainly not a complete one)
**\<kenshamir[m]>** right, it would be interesting to see how much certainty you can produce from such a graph in terms of monero
**\<sarang>** Initial estimates show that it's extremely low
**\<sarang>** but that assumes no external knowledge
**\<suraeNoether>** depends on the size, really.
**\<kenshamir[m]>** I don't know much about it, however I am assuming that it can be used to show how certain one can be that two outputs are linked
**\<suraeNoether>** i mean, a graph where everyone churns 100 times before spending... huge graph... obviously going to have a ton of false results
**\<sarang>** Right, but if done poorly, you can develop heuristics on partial matchings
**\<kenshamir[m]>** I wonder how external data influences the graph, and what type of external data
**\<sarang>** That's the big question on this research
**\<sarang>** Without that, it's purely academic
**\<kenshamir[m]>** As in a real-world scenario, an adversary will have access to external data. I believe the strongest adversary would be an exchange
**\<kenshamir[m]>** oh right
**\<sarang>** Exchanges, governments, entities with broad access to network data
**\<sarang>** It's a big part of why these sublinear schemes are so critical in research
**\<sarang>** At some point, any useful graph data gets lost in the noise of large anon sets
**\<sarang>** (this does not eliminate all types of analysis, of course)
**\<kenshamir[m]>** So the strongest type of external data, would be to know who owns some percentage of outputs and who they are?
**\<suraeNoether>** kenshamir[m]: that's part of it
**\<kenshamir[m]>** \<sarang "At some point, any useful graph "> Yep right
**\<suraeNoether>** kenshamir[m]: periodicity can be used to great effect, too
**\<sarang>** True, timing can play a large role
**\<sarang>** both in anon set selection and tx operations
**\<kenshamir[m]>** \<suraeNoether "kenshamir: periodicity can be us"> Could you explain?
**\<suraeNoether>** IP data from the network when you ctrl-v your txnid into a block explorer without tor immediately after the transaction is relayed
**\<kenshamir[m]>** Is that "I see a payment being sent every monday at 7pm"
**\<kenshamir[m]>** \* Is that "I see a payment being sent every monday at 7pm"?
**\<suraeNoether>** kenshamir[m]: okay well, imagine you are a churner with a superstitious streak and you like to churn every 88 minutes
**\<suraeNoether>** that chain of churns will stick out like a sore thumb
**\<sgp\_>** Joining now and caught up, hello everyone. I agree this matching paper is top priority right now
**\<suraeNoether>** a smart churner selects the age they wait between churns from the wallet distribution. then all the outputs in the ring are drawn from the wallet distribution and no timing data is leaked at all
**\<kenshamir[m]>** Right, that makes sense
**\<suraeNoether>** but any sort of additional data like IP address or timing can be merged together into a big bayesian updating machine and you can develop pretty good (if probabilistic) behavior profiles of users. and this applies to zcash and monero
**\<kenshamir[m]>** suraeNoether: do you mind going into some detail on how you are simulating?
**\<sarang>** So right now it's a balance between determining how many times to churn (to diffuse the graph) and how not to do it badly
**\<sarang>** To do this, we need better data (e.g. matching)
**\<suraeNoether>** kenshamir[m]: sure, let's do it after the meeting though because it's a little involved
**\<sarang>** OK, any other questions or work to present for this meeting?
**\<sarang>** going once
**\<sarang>** twice
**\<sarang>** OK, we are adjourned! Thanks to everyone for joining us. Logs will be posted to GitHub shortly

51
_posts/2019-07-25-logs-for-the-tini2p-dev-meeting-held-on-2019-07-25.md Normal file
View File

@ -0,0 +1,51 @@
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-07-25
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**tini2p** 0: Greetings
hello all
1: What's been done
merged ECIES updates for 144 updates + my spec suggestions: tini2p/tini2p!12
had a long discussion about 144 at this week's LS2 meeting: tini2p/meta#23
getting closer to a solid spec there, though there is still quite a bit to get done / come to consensus on
more updates to 152, and got rid of Blowfish: https://gitlab.com/snippets/1878282
**tini2p** basically, instead of using Blowfish for nonce encryption, tunnel gateways will keep a nonce counter
they advance the counter for every set of tunnel messages, concatenate the counter to the random tunnelNonce, and participants use the counter to ChaCha20 encrypt the tunnelNonce
participants don't change the counter value, but do need to verify it against an independent Bloom filter
there may be a fancy way to validate uniqueness of the counter without a separate Bloom filter, or save space by having a sliding Bloom filter with fewer elements that advances as it becomes full, TBD
the naive way is just to have two Bloom filters though: one for the tunnelNonces, one for the counters
**tini2p** unfortunately had to spend more time than I wanted working on specs this last week, so didn't make as much progress on code as I wanted
began work on ECIES tunnels, and have the BuildRequestRecord and BuildReplyRecord basically done: https://gitlab.com/tini2p/tini2p/tree/tunnels
2: What's next
I'll be spending the remainder of today working on tunnels, trying to get them "finished" (aka functional)
if I can't get them done today, I'll push back alpha release one more week. will do all I can to complete the work on end-to-end communication through tunnels
I could just "ship it" today, but tunnels aren't complete. I would really like to have an end-to-end functional setup in alpha release, even without interop with existing I2P network
**tini2p** even with interop, I will be setting a testnet netid, so communication with the main I2P network would require custom compilation
so, my focus will be on getting ECIES tunnels working with ECIES-only tunnels, and using the new layer encryption proposed in 152
hopefully, that will be finished by next week
after that, I will implement mixed tunnels with ElGamal participants, and the existing tunnel layer encryption
3: Questions / comments
**tini2p** 4: Next meeting time
2019-08-08 18:00 UTC
if I'm able to make alpha release by next Thurday, I'll make an announcement in here as well.
no meeting next week otherwise
**David Burkett** :thumbsup: Keep up the good work @tini2p_gitlab
**tini2p** thanks @DavidBurkett :smile:
**David Burkett** If you ever need me to help test anything, I'll gladly do so. Just let me know.
**tini2p** will do, thanks for the offer!!
thanks to all for attending / reading
meeting over

206
_posts/2019-07-28-logs-for-the-dev-meeting-held-on-2019-07-28.md Normal file
View File

@ -0,0 +1,206 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2019-07-28
summary: Development status, Code & ticket discussion, Moving off GitHub, and miscellaneous
tags: [dev diaries, core, crypto]
author: el00ruobuob / rehrar
---
# Logs
**\<rehrar>** Alright, it's time to start ladies and gentlemen.
**\<rehrar>** 1. Greetings
**\<rehrar>** Anybody out there?
**\<rbrunner>** Nope. All people on holiday.
**\<rbrunner>**
**\<vtnerd\_\_>** yes
**\<rehrar>** well, the three of us can have a grant ol time then
**\<rehrar>** just pinging hyc moneromooo dsc\_ selsta and dEBRUYNE also
**\<rehrar>** maybe a luigi1111 and fluffypony in the mix too, who knows
**\<rehrar>** either way
**\<rehrar>** 2. What's been completed since last meeting?
**\<dsc\_>** dont ping me broooo
**\<rehrar>** \_csd
**\<rehrar>** there, I took it back
**\<dEBRUYNE>** CLI v0.14.1.2 has been released
**\<dEBRUYNE>** Which is mostly bug fixes I guess
**\<dEBRUYNE>** mooo is holding a vacation, but he provided me a list of stuff that is ready to be merged
**\<dEBRUYNE>** So I am working with luigi to get the merge queue relatively empty
**\<kinghat>** 🙏
**\<rehrar>** ah, did not know mooo was on vacation
**\<rehrar>** I hope he ignores my ping then. Sorry!
**\<dEBRUYNE>** For the GUI, we tagged 0.14.1.2 and we're waiting on pony to finish the builds
**\<dsc\_>** I'm more than half way into integrating i2p-zero and tor into GUI
**\<dEBRUYNE>** Main new feature is optimized Tails support
**\<dEBRUYNE>** Perhaps dsc\_ can share a bit more detail
**\<dsc\_>** Sure thing.
**\<rehrar>** dsc\_: that's actually super exciting
**\<dsc\_>** So Tails integration is a collection of improvements that improve user experience for our Tails users
**\<dsc\_>** You would be suprised how big the audience is there
**\<dsc\_>** So, starting from 0.14.1.2 it will be very easy to use GUI on Tails
**\<dsc\_>** As for i2p-zero, I need a couple of days then that's done too
**\<dsc\_>** I suggest to package i2p-zero with the GUI release
**\<dsc\_>** Which can pose problems for our reproducible build efforts
**\<dEBRUYNE>** I don't see much harm in packaging it with the GUI, especially if the user first has to check a checkbox to turn it on
**\<dsc\_>** but that's a problem for later
**\<dsc\_>** That also
**\<rbrunner>** Shouldn't the CLI pack it also then?
**\<dEBRUYNE>** I think most CLI users are able to download the package themselves
**\<dEBRUYNE>** And get it running (especially given the instructions present on Github)
**\<dEBRUYNE>** By contrast, GUI users need a checkbox and not tons of steps
**\<rbrunner>** Ok, makes sense, more or less ...
**\<dsc\_>** The fact we package i2p-zero is a convienence feature. I'm also 'integrating' support for Tor but we wont be packaging that. That's basically running Tor and using socks proxy at :9050
**\<rehrar>** we GUI people are scrubs
**\<xmrmatterbridge> \<xmr-romine>** is there already some doc about running monerod over tor ?
**\<dsc\_>** https://github.com/monero-project/monero/blob/master/ANONYMITY\_NETWORKS.md
**\<dEBRUYNE>** https://github.com/monero-project/monero/blob/master/ANONYMITY\_NETWORKS.md & https://github.com/monero-project/monero#using-tor
**\<xmrmatterbridge> \<xmr-romine>** thanks guys
**\<rehrar>** hyc any update on randomx audit?
**\<rehrar>** The last one?
**\<dsc\_>** One more thing regarding i2p-zero.. It can take up to 1-2 minute(s) for the local socks proxy to become 'active' which means, if the user has i2p-zero enabled and starts up the GUI to create a quick tx ... might have to wait a minute or two
**\<dsc\_>** This is related to how i2p-zero works
**\<dsc\_>** so beware of that limitation
**\<rbrunner>** So it's i2p-two, from "two minutes"?
**\<kinghat>** can it check if i2p is currently running?
**\<dsc\_>** rbrunner: haha
**\<rehrar>** it's how i2p works in general, no? Getting bootstrapped into the network, I mean.
**\<dsc\_>** rehrar: most likely
**\<dsc\_>** kinghat: it can
**\<rehrar>** under bad circumstances it can take even longer
**\<rehrar>** I wonder if there can be some kind of notification to let users know this
**\<vtnerd\_\_>** tor should have similar issue iirc, building circuits isn't immediate
**\<kinghat>** also, are we still going to do the beta builds for the gui?
**\<dsc\_>** vtnerd\_\_: Sure, but not 1-2 minutes?
**\<dsc\_>** kinghat: yes
**\<kinghat>** 👌
**\<vtnerd\_\_>** I think it might be longer than that, at least it seemed like forever yesterday when I was testing
**\<vtnerd\_\_>** actually no, I've run tails once before, it takes some amount of minutes, just don't remember the exact time frame
**\<dsc\_>** vtnerd\_\_:
**\<dsc\_>** $ time (sudo service tor restart && sleep 2 && torify curl icanhazip.com)
**\<dsc\_>** 171.25.193.77
**\<dsc\_>** real0m2.759s
**\<vtnerd\_\_>** if your not using outbound connections tor destroys the circuits and goes into an idle mode too, which isn't a problem if "noise" is enabled (because its always sending)
**\<rehrar>** there goes dsc\_ bragging about his internet again
**\<dsc\_>** yes, my internet.
**\<vtnerd\_\_>** it keeps state in a file that it might re-use, so you'd have to a cold restart
**\<dsc\_>** vtnerd\_\_: fair enough
**\<rehrar>** alright, anything else?
**\<dEBRUYNE>** vtnerd\_\_: I was wondering if you intend to pick this up somewhere in the future? https://github.com/monero-project/monero/pull/2317
**\<vtnerd\_\_>** see https://github.com/monero-project/supercop/pull/2
**\<vtnerd\_\_>** this one and the next one after that PR is a bit rough because its x86 ASM
**\<rehrar>** that was a hilarious conversation to witness
**\<rehrar>** person 1: i was wondering if git link
**\<rehrar>** person 2: Well you see it's like git link
**\<dEBRUYNE>** Thanks
**\<vtnerd\_\_>** Im also not certain that having a separate repo for this is beneficial, but I guess some other project could make use of the custom hooks
**\<vtnerd\_\_>** my original code should need some re-working since the device/ledger stuff got slammed in, but I look at recently and I think its possible to rebase/update that without crying
**\<vtnerd\_\_>** Im also not certain whether that supercop repo should be an external git thing, or something that you manually have to do
**\<vtnerd\_\_>** I'm thinking the latter, since people are blasted without another submodule
**\<vtnerd\_\_>** \*are not
**\<dEBRUYNE>** I see, seems like a thing that warrants more in depth discussion in a future dev meeting
**\<rehrar>** With more attendees?
**\<rehrar>** serious question
**\<rbrunner>** And maybe some more background info to prepare
**\<rehrar>** who should be present for such a discussion?
**\<rehrar>** we can add it to next meeting as an item and try to ping the people to be there
**\<vtnerd\_\_>** the background is either the supercop code goes as a submodule and it must be synced by every person
**\<vtnerd\_\_>** or only those that which to accelerate wallet scanning drop the repo into a folder and toggle a cmake bit
**\<rbrunner>** So that's not something for the normal, general release then?
**\<vtnerd\_\_>** its not needed for testing, unless you need to test the feature specifically
**\<vtnerd\_\_>** no, likely it would be in the normal general release, but I suppose it doesn't have to be
**\<vtnerd\_\_>** this came up because ryo recently added support for basically the same thing, and it should cut wallet-scanning time in half
**\<vtnerd\_\_>** although its probably dependent on your HD speeds too
**\<rehrar>** alright, any more discussion on this?
**\<hyc>** re: randomx audit, Quarkslab are finalizing their report, said we may get it by middle of next week
**\<rehrar>** nice!
**\<rehrar>** does anyone have anything else that they want to discuss?
**\<hyc>** since they've been opening github issues as they arose, there's not likely to be anything in the report we haven't already seen
**\<ErCiccione>** yep! https://github.com/monero-project/meta/issues/236#issuecomment-515669422
**\<ErCiccione>** GitHub is starting to censor people coming from countries under US sanctions, we should definitely migrate away
**\<ErCiccione>** i don't know how the core team feel about it
**\<rehrar>** do people here have any thoughts about the Github/Gitlab thing, especially in light of the recent Github things?
**\<vtnerd\_\_>** those countries listed probably require some vpn/tor/i2p opsec to contribute anyway ... ? I'm certainly not attempting to stop a switch to a self-hosted gitlab, but meh
**\<rbrunner>** If such a switch was so easy it would probably have happened already, I think, after the Microsoft acquisition ...
**\<vtnerd\_\_>** or maybe not, but they would have to after that hammer that was thrown
**\<rbrunner>** With all submodules still on GitHub, for example
**\<vtnerd\_\_>** the support team for the gitlab instance are probably the most relevant for this
**\<ErCiccione>** rbrunner: the point was to test monero-site on the self-hosted gitlab first, and then see what to do with the other repos. But has been almost an year now
**\<hyc>** I've always favored moving to self-hosted gitlab and away from github
**\<rbrunner>** Yeah, I remember. But I think the site is a particularly simple case
**\<vtnerd\_\_>** I mean most devs should have a copy of the code and history luckily, but its the discussions that can get purged if not backed up properly
**\<hyc>** but this particular issue only affected private, paid github accts
**\<hyc>** (i.e., github closing off accts from sanctioned countries)
**\<ErCiccione>** hyc: i guess that depends by how they are forced to enforce the sanctions
**\<hyc>** https://twitter.com/natfriedman/status/1155533738278699008
**\<hyc>** https://twitter.com/natfriedman/status/1155311121038864384
**\<hyc>** they're splitting some hairs I guess. trade sanctions only affect commerce. if you paid for a private acct, you're affected.
**\<rbrunner>** Has any other notable cryptocurrency team already made such a switch?
**\<hyc>** if you're on a public/free acct, you're not affected
**\<rehrar>** rbrunner: define notable?
**\<rbrunner>** I mean, some "interesting" team. Top 100 coin, maybe? Sizeable community, I mean
**\<ErCiccione>** thanks for the links. it's still a very precarious situation.
**\<ErCiccione>** rbrunner: sia
**\<rbrunner>** And complexity of the code
**\<hyc>** ErCiccione: agreed. as I already said, I'm in favor of moving off.
**\<kinghat>** i think ppl are worried about contributions after moving off github. i dont think it would make a difference.
**\<hyc>** again, just my perspective: the OpenLDAP Project maintains our own repo. we only mirror to github, because it seems you're not a real project these days if you're not on github
**\<hyc>** out github mirror is read-only
**\<hyc>** our\*
**\<ErCiccione>** kinghat: i agree.
**\<dsc\_>** I keep repeating myself but I question people whose first thought is 'gitlab' when thinking of a git alternative
**\<dsc\_>** There is more! Noooo.. Yes!!
**\<dsc\_>** Consider it...
**\<hyc>** gitea?
**\<dsc\_>** for example, yep
**\<hyc>** I don't really care which alternative is used. all I care is self-hosted.
**\<ErCiccione>** iirc gitea was considered
**\<hyc>** you could make an argument that being off github adds a barrier to entry - people don't like having to create accounts just to interact with another project
**\<rehrar>** In favor of gitea
**\<dsc\_>** Even more so when considered gitlab is a company, enterprise, they have funding, maybe they have shareholders - and capitalism is evil. Therefor, gitea
**\<rehrar>** hyc which is why I am arguing for a federated git ecosystem
**\<rehrar>** open issues on another git based project management site from yours, etc
**\<ErCiccione>** let's not forget that we already have half repos on github and half on gitlab. That's not ideal
**\<hyc>** rehrar: agree, federated identity would be preferable
**\<rehrar>** let's build it
**\<rehrar>** we can have it out by Wednesday at the latest
**\<hyc>** +1
**\<dsc\_>** ok sounds good
**\<ErCiccione>** i want 2
**\<rehrar>** that'll take an extra day
**\<hyc>** this could be a long conversation, but totally - we need to rethink the notion of accounts and identities
**\<rehrar>** But for reals though this is an ongoing discussion and...
**\<rehrar>** ^ hyc
**\<rehrar>** we have the issue open about this that ErCiccione
**\<rehrar>** although that one is about moving to gitlab, I think
**\<rehrar>** so maybe another one can be opened for discussion on which platform?
**\<dsc\_>** +1 for centralized authentication service
**\<dsc\_>** (hosted by monero)
**\<rbrunner>** Oh the added complexity
**\<dsc\_>** rbrunner: for whom?
**\<rbrunner>** The system in general, I mean.
**\<dsc\_>** It could simplify things
**\<hyc>** not quite centralized authent. just public key based.
**\<rbrunner>** Something more that can go wrong
**\<ErCiccione>** rehrar it is yes, as hyc says for me the important is to move away from a centralized place. I think gitlab is the best choice because we have been testing it for an year, but sure let's discuss alternatives
**\<hyc>** we could use monero wallet addresses as our identities
**\<rehrar>** hyc I've been thinking of using Monero signatures as password alternatives
**\<dsc\_>** thats a cool idea
**\<rehrar>** public key as ID
**\<rehrar>** signature from private key as password
**\<kinghat>** does that work with subaddys or am i missing something?
**\<rehrar>** but then losing your seed is even a bigger deal
**\<rehrar>** or getting it stolen
**\<hyc>** good point
**\<rehrar>** as long as there are standard ways of resetting or something
**\<rehrar>** it's no more annoying than losing or getting your regular password stolen
**\<hyc>** having a reset facility implies a centralized admin authority
**\<dsc\_>** Call the Monero helpdesk and provide them your miaden name, your first car brand and your date of birth
**\<hyc>** ^
**\<rehrar>** enforced 2/3 MFA then
**\<hyc>** should we wrap up the mtg before continiung this conv?
**\<rehrar>** but yeah, we'll call it here
**\<rehrar>** unless anyone has any last minute things?
**\<vtnerd\_\_>** I hope to finally issuing some PRs related to the i2p/tor white noise stuff, took some time to architect this bt hopefully. nothing else needs to be reported by that really other than look for more stuff to review
**\<rehrar>** cool deal!
**\<rehrar>** well everyone, thanks for making the time today.
**\<rehrar>** You're all free to disperse. Coffee on the little table outside the meeting room.