Monero Bi-Weekly Dev Meeting Note Highlights – 2016-08-14
Logs
351 lines
wallet42moneromoo: rewview guidelines?
moneromooowallet42: well, whatever you feel comfortable with. Do you have anything in mind ?
i2panonimalIs there a meeting in a few minutes?
moneromoooThe most important is potential for exploits.
moneromoooYes.
hycawesome
moneromoooWell, assuming the pony isn't too busy with mymonero.
darkcoinspyget your notepads out everyone. time to take notes on the competition
i2panonimalWhich competition?
moneromoooI think he just meant dash is still around. It's another crypto (ex darkcoin).
dEBRUYNE<moneromooo> Well, assuming the pony isn't too busy with mymonero. <= he was online 20 min ago, fwiw :p
hycfixing mymonero…
dEBRUYNE:-P
alex___what happened to mymonero?
hycits blockchain got stuck
alex___ah ok
dEBRUYNEalex___: <_Telegram> <fluffypony> there were like 6 imports running which deadlocked the database
hycI thought we fixed db_open to disallow more than 1 process on the DB at a time
moneromoooMight be talking about his sql db I think.
hycah
hyctoo bad. we've been working on an LMDB backend for mysql/mariadb but not much progress in a long time
DaveyJonesisnt there supposed to be a meeting? xD
JjegrUseinobyes
JjegrUseinobwaiting on poniex
JjegrUseinobponies
hycfluffypony fluffypony fluffypony ?
JjegrUseinobfluffypony may be drinking wine right now
JjegrUseinobhave you seen his wine rack?
i2panonimalYes, epic.
JjegrUseinobim about to go get a drink myself
JjegrUseinobbrb
hycgood idea
dEBRUYNEmoneromooo, hyc: perhaps someone else can take the lead until he returns?
hycif we had an agenda in advance that'd work. I've got no idea what needs to be covered today
moneromoooWell, I have just one thing to say, really: reviewers wanted (even for part of the stuff).
hycOK, that's a good topic. So there's now a PR for the RingCT code
hycwhich means it's presumably functionally complete and ready for heavy testing
dEBRUYNE<hyc> if we had an agenda in advance that'd work. I've got no idea what needs to be covered today <= let's just discuss Ring CT first and the additional open PRs
DaveyJonespaging othe, luigi1111w, luigi1112, othe, tewinget too
i2panonimalCongratulations to everyone involved on that. Its a big one.
moneromoooYes. I don't think I've got anything else to add, until luigi finds something else he wants to change.
DaveyJonesmaybe smooth too
moneromoooBut reviewing this isn't going to be wasted anyway, even if he finds something.
dEBRUYNE^ NoodleDoodle, ArticMine
DaveyJonesbut the agenda thing would be nice for such incidents
dEBRUYNEmoneromooo: Is there a way people can help with testing?
i2panonimalmoneromooo: is there anything in particular that needs attention in terms of review?
ArticMineRingCT is going to need heavy testing and a public testnet would be a great asset for this
moneromoooWell, the private fork branch is out of date now, there'll be a public testnet once there's a modicum of review I expect.
wallet42I would love to setup and pay for a public testnet with a couple nodes
dEBRUYNEFwiw, there's a guide to setup a private tesnet -> https://moneroexamples.github.io/private-testnet/
fluffyponysorry just got in
luigi1112Sounds good :-)
fluffyponywas eating
moneromoooHay.
moneromoooer, I mean… hey.
hycLOL
DaveyJonesLOL
dEBRUYNEPeople could apply the RCT PR to the code and test it on their own private testnet
fluffyponyok so
moneromoooIt's already based on latest master. I did removed the forking setup though.
fluffyponymoneromooo: you mean the PR?
moneromoooYes.
moneromoooI kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
fluffyponydoes the PR have a fork date?
moneromoooNo.
wallet42how to activate it?
dEBRUYNEmoneromooo: I meant apply as in manually add it because it hasn't been merged yet :-P
i2panonimalThanks for the link dEBRUYNE
moneromooowallet42: it will activate at the right height, once it is cchosen.
i2panonimalI have to run folks, I'll read the backlog tomorrow.
moneromooosee ya
fluffyponycheers anonimal
luigi1112Yeah it shouldn't have a date
fluffyponymoneromooo: I don't understand the "right height" thing, plz explain
moneromoooEntries in the hard fork table in src/blockchain.cpp.
moneromooo(which do not exist yet)
dEBRUYNEI think we should set a height that adds 1-2 months to the height after this process has completed -> <moneromooo> I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
fluffyponyso as this stands
fluffyponyit understands v3 transactions
dEBRUYNERing CT is such a big change that I think we could deviate once from the HF schedule
moneromoooLet me explain versions and stuff about this:
fluffyponyk
moneromoooCurrently, we are on HF 2, and tx version 1 is the only one that exists.
moneromoooAt HF 3 (september on mainnet), pretty much nothing changes.
moneromoooAt HF 4 (march), rct txes (v2 txes) are allowed. At HF 5 (september in a year), v1 txes are disallowed, except for sweep_unmixable.
moneromoooThough the last bit (sweep_unmixable) might be unnecessary, I'm unsure.
fluffyponyok
hycsounds fine
moneromoooOh, and at HF 4 (when rct txes are allowed), the coinbase gets in a single out, and is stored as rct, despite not being rct.
moneromoooSo they can be spent along with rct fake outs.
fluffyponyoh neat
hycso that also means no quantization then?
moneromoooYes.
dEBRUYNE"v1 txes are disallowed" -> does that mean everyone needs to move their coins or will a one time transaction be allowed after that?
moneromoooAn rct tx may spend pre-rct outputs.
fluffyponydEBRUYNE: nobody needs to move anything yet
fluffyponyor ever, really
hycright, this doesn't affect existing outputs. only newly generated txs
luigi1112The block reward thing is neat if it works :-)
JjegrUseinobso what will september HF do then?
dEBRUYNEfluffypony, hyc: thanks, was asking for clarification
moneromoooIt does. Was a pita due to breaking the tests, but it all works now :D
fluffyponyJjegrUseinob: roll over to stick to the schedule, include the next HF date so that nodes notify
fluffyponyand also include all the fixes to-date
luigi1112Quantize the reward afaik
moneromoooSeptember fork just enforces the coinbase to be split into denominations.
luigi1112(Does someone know the state of pools?)
fluffyponymoneromooo: are we going to point release with the rct PR merged or before then?
ArticMineDoes the September HF force min 4 mixin?
hycand that's not a significant brhavior change, right? it was always supposed to be split
moneromoooIt was suppose dto, but not enforced.
luigi1112Rct doesn't really make a difference..it's just dead code until activated
luigi1112So the question is are there still offending pools that need to update
moneromoooI'm mostly bothered about having this huge chunk of stuff that creats conflicts with evreything now.
fluffyponyluigi1112: guaranteed that MinerGate is still using their custom stuff and just fudging the version
hycyou're talking source code merge conflicts?
hycor something else moneromooo?
moneromoooLike, my cold wallet tx patch is now based on rct code.
moneromoooYes, git conflicts.
fluffyponyI don't have a problem with RCT being merged before the point release
luigi1112fluffypony: that's fine :-) anyone else
dEBRUYNE<luigi1112> (Does someone know the state of pools?) <= I can check headers
fluffyponytewinget: what's the status on 0MQ?
luigi1112I guess minor version and the block reward are good things to check
fluffyponymaybe we should push for that in the point release if it's nearly done
luigi1112(Being denominated)
dEBRUYNEBtw fluffypony, in case tewinget isn't here
luigi1112Th at can probably be done in the interim between Sept and march?
dEBRUYNEThis is from the logs:
dEBRUYNE<tewinget> I'm a few hours of work (I hope) away from having the wallet using zmq to talk to the daemon
moneromoooHe said he was starting work on getting the wallet to talk 0MQ yesterday (he'd been using python client with the daemon).
fluffyponyok
dEBRUYNEluigi1112: minor_version should be 3 right?
hycyes, tewinget was asking for reviews of his branch too
moneromoooI guess I should go look ^_^
dEBRUYNEanyway, minergate is on "major_version":2,"minor_version":3
dEBRUYNEFor anyone interested, the 0MQ branch can be found here -> https://github.com/tewinget/bitmonero/tree/zmq-dev
dEBRUYNEmoneromooo, fluffypony, luigi1112: This is Minergate's coinbase transaction -> http://moneroblocks.info/tx/8a6f45c079da5e400632c29e6b8145fda593a44657881d6d91b232769511c8fc
fluffyponyok
dEBRUYNEAre there any additional meeting items?
hycquick update on 32-bit support - my blockchain_import is still running :P
fluffyponylol
luigi1112dEBRUYNE: what about other pools?
dEBRUYNElemme check
fluffyponyre: the RCT PR, I think we should aim to finish up review and merge by next weekend - any objection, moneromooo ?
moneromoooThat'd be pretty fast.
moneromoooIf you can find enough reviewers by then :)
fluffyponythere will be more review post that
fluffyponyoh btw moneromooo
fluffyponywhat are your thoughts on the testnet fork dates?
moneromoooI should add: along with the rct stuff, that branch has random fixes that would otherwise conflict: better output selection, no signatures stored in wallet, fixes to avoid having to run rescan_spent (I think I got them all).
moneromoooI think a few days after all preliminary review + fixes are done. Then 1 day between 3 and 4, and a few days between 4 and 5 (where both tx versions are allowed).
hycmoneromooo: as long as those are each in their own commits, we can still tick them off 1 by 1
moneromoooThey are, yes.
fluffyponymoneromooo: so then once merged, say next weekend, we can PR testnet fork points
moneromoooYes.
JjegrUseinobi never saw clear answer to artic mine question about when min mixin of 4 will be enforced
moneromoooNo change there for now, but there should be.
hyccan we do it this Sept HF?
JjegrUseinobthank you moo and hyc. your hard work is appreciated
dEBRUYNEluigi1112: All pools listed here -> https://monerohash.com/#network have "major_version":2,"minor_version":3
fluffyponyok
fluffyponyI think that's about it then - code review time
moneromooo<hyc> can we do it this Sept HF?
moneromooo(about bumping the network minimum mixin)
hycright
DaveyJonesso is there a way some chosen folks can put items into an agenda for dev-meeting… just in case fluffy or anyone else dont have time to lead the meeting
moneromoooYou can always ask something dev related if you wish.
DaveyJonesso people like debruyne could atleast try to take the host
moneromoooIt doesn't need to be made known in advance (unless it requires research)
hycmebbe propose agenda items on forum.getmonero.org or something
ArticMineHaving an agenda ahead of time can be helpful. It does not need to be cast in stone.
JjegrUseinobanonimal usually has kovri meeting agenda in advance. i like that system
DaveyJonesi mean this was the first real dev meeting for a month or sth and even today we had a eating hiccup :p
JjegrUseinobwhen will log from last meeting be on the website?
fluffyponylol DaveyJones
fluffyponyJjegrUseinob: sometime next week, once dEBRUYNE has a chance
JjegrUseinobhttps://getmonero.org/blog/tags/dev%20diaries
JjegrUseinobi said last meeting
JjegrUseinobpr was merged already
JjegrUseinobhttps://github.com/monero-project/monero-site/pull/135 hellocccc has quit (Ping timeout: 264 seconds)
fluffyponyJjegrUseinob: there are issues that have to be fixed
fluffyponyeg. fluffypony Missing key: menu.stackexchange fluffypony Liquid Exception: exit in _layouts/default.html
fluffyponyso I've got to fix those first
dEBRUYNE<fluffypony> JjegrUseinob: sometime next week, once dEBRUYNE has a chance <= I'll PR the logs tomorrow
fluffyponyplanning on doing it tonight
dEBRUYNE(today's)
JjegrUseinobok ty
dEBRUYNEAnyway, perhaps we should put a bit of thought into whether we want to activate Ring CT in march (and thus on a scheduled date) or activate earlier on a "random" date
hycnot sure there's a reason to break the schedule
hyc ?
JjegrUseinobcompetition from zcash seems like a good reason IF rct is ready to activate and tested enough
moneromoooI just realized it reads like Z(ooko)Cash.
DaveyJonesthat was intented i guess :p
ArticMineI am with staying on schedule with RingCT in March.
luigi1112I think rushing because "competition" is I'll advised here
luigi1112Ill
grimpantsyes
hycagreed
ArticMineVery ill advised
moneromoooThe thing I'd move if we could is the september one, to a bit later, but that might break non-updaters…
moneromoooAs we need to have a binary a couple weeks before, in order for most to update in time.
luigi1112I don't think we should enforce mix 4 here since it's not in existing code
dEBRUYNEIt's good to hear thoughts from everyone on this subject
luigi1112It'd be a rush release
ArticMineThen min mix 4 is scheduled for March?
DaveyJonesquestion is … are non updaters an issue atm? i mean we are still small and in a small community people should be able to update once in 6 months ?
luigi1112Mix 4 goes well with rct
luigi1112I'm not sure it needs to be enforced until v1 is disallowed
ArticMineSo let us make it for march
luigi1112That's not till 1 year from now by current rhoughts
moneromoooThat'd be september, for v1 to be disallowed.
gingeropoloussomeone mentioned that moving the HF date up would, in general, be good for those that need truly private currency. But I also see the benefit of sticking to schedule
moneromoooWell, stuff like the new coin selection will be active as soon as it's merged, since it's wallet behavior. So there'll be some betterment already.
moneromoooAnd transfer maps to transfer_new, too. So no more shitty dust for multi-tx.
gingeropolousi wanted to try and get into that code for the "find set that matches" behavior… someday.
JjegrUseinobwhy cant we point release those improvements soon then and have ringct fork late oct or nov?
JjegrUseinobfor march enforcement
moneromoooIt's a difficult problem to find the best set.
niocIt had been mentioned previously that in the early stages the HF schedule could be adjusted considering the important changes that need to be implemented.
moneromoooI don't think it's particularly important to keep to the march date, since I doubt many people will bang on testnet once a new release is out, so it'd just wait there.
moneromoooI mean, more time would not mean more testing.
gingeropolous<JjegrUseinob> why cant we point release those improvements soon then and have ringct fork late oct or nov? - well, the arguments against this is that we're setting precedent for non-scheduled, at-whim, as-needed forking, and if we're trying to create a culture of "forking is ok", then the schedule has a particular… weight to it, perhaps
hychardforks good, more is better :P
JjegrUseinobi thought that monero had a social contract that largely supported flexibility this year for rct fork
gingeropolousbut im on the fence as well… I still think we're small enough of a thing that we could pull it off
dEBRUYNEIt was discussed before that if we would deviate from the schedule, we would only deviate once for RCT
fluffyponyMonero Classic is going to have weekly hard forks
moneromoooYes. Hardforks every two months, maybe many of them not actiually changing anything… would allow easy scheduling of changes without havinhg to wait forecer.
fluffypony:-P
fluffyponyJjegrUseinob is right though
gingeropolousautoupdate all the things. moo's favorite
fluffyponywe did say that we might adjust them at the beginning, and that we'd taper down to annual hard forks (or further apart) later on
DaveyJonescan we have replay attacks too? for classic
fluffyponyso if testnet is successful and everything is fine we can consider moving itup
fluffypony*it up
JjegrUseinob:
JjegrUseinob:)
hycok, that sounds fine. when we're happy with the code integrity and test phase
gingeropolousim down with that. Fork early, fork often
moneromoooAnd bump mixin at this one ? Or the one after it ?
DaveyJonesmonero is a flexible adolescent… we will stiffen by time :p
dEBRUYNE<fluffypony> so if testnet is successful and everything is fine we can consider moving itup <= I'd be fine with that too
dEBRUYNElet's make sure miners have enough time to update and receive notification
fluffyponymoneromooo: bump mixin at Sept hardfork
dEBRUYNEso 1-2 months after the full "process"
fluffyponymixin will bump anyway for rct right
moneromoooSo HF 5 ? Which might not be september if we being march forward.
moneromoooMin mixin was not touched in the rct banch.
fluffyponyoh
fluffyponywe're going to have to bump it for definite
luigi1112Don't bumb for September imo
luigi1112Bump
luigi1112It's too soon
hycI suppose it ought to run on testnet first
moneromoooSo 4, in HF 4 (with rct enable) ?
luigi1112This september
luigi1112I vote for next September but I'm somewhat ambivalent vs march
ArticMineIs there a reason for Sept 2017 vs March 2017 for enforcing mixin 4?
luigi1112Yes, it is better with ringct
luigi1112Which will be enforced then
moneromoooOh, and the size increase as a function of mixin is rather shallow. So we can go wild.
hycit seems to me min mixin 4 is a good thing regardless of rct. why wait
luigi1112It adds forced "junk data" for 6 months…but not a large deal most likely
moneromoooIt's not junk, it's lovely privacy preserving data :P
moneromoooOr we can do 3 in march, 4 in september :)
ArticMineSo an additional TX size issue for six months that is solved with RingCT
moneromooorct txes will be larger.
moneromoooAbout 13 kB I think. A lot more constant than current.
ArticMineBut there is a tradeoff in the need to mix the inputs broken down in powers of 10
moneromoooAh, you mean to get a "privacy equivalence" ?
ArticMineYes
moneromoooThe new coin selection should help there too I think.
hycwe should be winding up and letting the kovri mtg start
hycdo we have any decisions on bumping mixin?
moneromoooanonimal left, no kovri meeting.
hycok
moneromoooI guess I'll do mixin 4 for HF 5 then, unless new stuff gets said.
ArticMineSounds fine to me
hycok
moneromoooAs an incentive for reviewers to review, my cold wallet signing patch is now based on the ringct branch, so it can't be merged without rct being merged first ^_^
JjegrUseinobcold wallet signing patch will be a great feature. thanks mooooo
fluffyponyok I fixed the stuff that was breaking on the site
tewingetfluffypony: what dEBRUYNE said.
tewingetI totally forgot there was a dev meeting and slept right through it, woops.
moneromoooYou can still tell us how far you are, most people are still in the channel :)
othebetter than me, i thought i am in this channel…but i wasn´t
tewingetWell, there's 5-10 daemon RPC commands yet to implement, but I'm leaving them for now because they're mining/miner related. Next thing to do (hopefully yet today) is some first pass at "libdaemonrpc" and making the wallet use it.
othedoes ur todo list include authentication too? the current way is kinda bah
tewingetothe: yes, but that will be something to look at after the rest is sorted, I think.
othegood
moneromoooOh, that reminds me.
moneromoooThe previous 0mq branch had something called net_skeleton, which was doing some middle layer ntworking stuff, but was GPL so needed replacing.
moneromoooHave you found a replacement ? Kovri uses cpp-netlib, and I was thinking using the same would be good if it fits, since more people would know, etc.
tewingetI'm just using zmq…
tewingetidk what he (oranjuice, I think?) was using net_skeleton for.
moneromoooYes, that was him/her. And I dunno either :)
othei only know that theirs a license issue with that anyway
othenvm…
othedidnt we want to replace epee with net skeleton?
tewingetothe: good question, to which I haven't an answer.
gingeropolousbe sweet to get a graphical version of whatever was decided re: HF and rule versions today
gingeropolousi.e., timeline
gingeropolouscause again, the lack of harmony with all these version numbers is confusing
fluffyponyoh
fluffyponytewinget / moneromooo
fluffyponynet_skeleton had nothing to do with 0MQ
fluffyponyonce 0MQ is in we still have to offer a JSON RPC API, right
fluffyponyand that has to be able to provide TLS and simple auth
tewinget<fluffypony> once 0MQ is in we still have to offer a JSON RPC API, right <– err…about that
fluffyponyso we'd have a new helper app for JSON RPC API
fluffyponytewinget: it's in the spec
tewingetthe zmq implementation thus far *is* a json rpc
fluffyponyno
fluffyponyJSON RPC API is a standard
tewingetoh, right, that
fluffyponyhttp://json-rpc.org
tewingetI mean, I've got it nearly identical to that standard, so it wouldn't take much doing to change it to exactly that
fluffyponyyou're just serialising data in JSON
tewinget test_str = {
tewinget "request": "get_blocks_fast",
tewinget "version": 1,
tewinget "message": {
tewinget "block_ids": ["418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"],
tewinget "start_height": 10
fluffyponythe HTTP-based JSON RPC API is familiar to integrators
tewinget }
tewinget }
tewingetthat's pretty close to the standard
fluffyponyso we have to provide that layer
tewingetI'll just have to change it a little
tewingetoh, you mean http-based
fluffyponyyes
fluffyponythat's what net_skeleton was doing
tewingetwhich spec do you mean, 1.0 or 2.0?
tewingetbecause 1.0 mentions HTTP, but doesn't specify that it's necessary as part of the spec, if I'm reading it correctly. :P
tewingetthat said, HTTP makes sense I suppose, just will take a bit of doing.
fluffyponyit's transport agnostic, but every single client library supports HTTP and no other transports, lol
fluffyponyok but back up a second
fluffyponydon't go running ahead and changing things just yet
tewingetwasn't planning to
fluffyponyif I'm a client application talking 0MQ to the daemon I need to have some optional authentication, which 0MQ provides support for
fluffyponyI'd only use that if I'm talking remotely to the daemon
tewingetwith you so far
fluffyponysame goes for encryption - not necessary on localhost
fluffyponyso then we have this little stub applications, let's call them monero-rpc-daemon and monero-rpc-wallet
fluffyponythey have an HTTP server
fluffyponyand they talk 0MQ to the daemon
tewingeteven that's slightly overcomplicated I think
tewingetjust monero-rpc-http as one binary
fluffyponyyeah that's fine too - as long as wallet-ing is optional
tewingetlaunch it with the correct bind ports and forward ports and it doesn't have to know which type of rpc daemon it's talking to
tewingetsame binary would work for both wallet rpc and daemon rpc (and others if ever there are any)
fluffyponyit can't be a dumb client though
tewingetright, it'll have to have auth parameters as well
fluffyponyotherwise you're going dumb client -> rpc-wallet -> daemon
fluffyponythree binaries
fluffyponyie. it has to have local wallet functionality
fluffyponythat talks to a daemon over 0MQ
fluffyponyie. simplewallet gets separated out into cli-wallet and rpc-wallet
fluffyponyboth of which use 0MQ to communicate with the daemon
fluffyponyand rpc-wallet can provide both HTTP and 0MQ interfaces, at a later stage, but definitely HTTP initially
tewingetso you're saying you want to wrap http-speaking into the rpc-wallet binary?
fluffyponysimplewallet already talks HTTP
fluffyponywhen you put it in RPC mode, I mean
tewingetdoesn't the daemon already do so as well with the current RPC?
fluffyponyyes - and we have to support that also to be backwards compatible, but that's another story
tewingetyou might hate this idea, but bear with me. I was thinking for backwards-compatibility to just leave the old RPC in place until it's completely deprecated, probably with a compile flag that disables compiling it in by default.
tewingetnot the cleanest solution, granted, but seems pragmatic imo
fluffyponyI do hate that idea, purely because I want to rip that code out :-P
tewingetso what I was thinking is to have the zmq rpc for whatever binary needs it (wallet, daemon, etc) and then have an optional transparent bridge for http (possibly less transparent if using SSL over http is desired)
tewingetbut having said bridge layer live inside the {daemon,wallet,etc} binary is okay too, I suppose.
fluffyponyso what happens if I'm a well-designed exchange, and I have the daemon on a different machine to the wallet
fluffyponyand I want to talk HTTPS to the wallet
tewingetHTTPS request -> wallet -> daemon? I'm not sure I understand why you ask.
fluffyponyyes precisely
tewingetor with the bridge as a separate binary, HTTPS request -> bridge -> wallet -> daemon
fluffyponythe daemon is exposed to the Internet
fluffyponyit can be attacked
fluffyponythe wallet is sensitive, so it lives behind the DMZ
tewingetokay…
fluffyponyyour second one solves the case as long as I'm happy starting up a bunch of things
fluffyponyalso you'd need rpc-wallet to provide a 0MQ interface
fluffyponyand then bridge -> wallet talks 0MQ
tewingetI intend for it to.
tewingetwhy would the wallet libs not have a 0mq interface? Need that anyway for GUIs and shit, right?
tewingeterr…nvm, dumb question
fluffypony0MQ client != 0MQ interface
tewingetyea, I was thinking the wallet would run and a GUI would connect to it via 0mq, but the GUI can just use libwallet directly.
fluffyponyyes
tewingetthat having been said, at some point off in the future I might look into using 0mq's intra-process stuff for message passing.
tewingetbut that's a long time in the future
fluffyponyyeah
tewingetso from a code reuse standpoint, to me it makes more sense to have a bridge binary that speaks HTTP(S) and 0mq, and to have both wallet and daemon speak 0mq.
fluffyponyyeah agreed
tewingethmm…even that's not necessarily true, it wouldn't be too bad to have both speak both.
tewingetor rather have the wallet just speak http(s) to the wild, and use libdaemonrpc or w/e to speak 0mq to the daemon
tewingetall of the message system I've written for the 0mq so far is transport-agnostic, so that's the good news :)
tewinget(as it should be, but I'm just pointing it out for the sake of…well, having pointed it out, I guess)
tewingetfluffypony: for what it's worth, libwallet will need to have the same type of messaging system as I've implemented in the daemon, and the zmq-specific stuff is tiny, so if we do decide we do want the wallet to speak 0mq it should be a (relatively) trivial change in the end.
fluffyponykk
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2016-08-14, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.