--- Log opened Tue Oct 18 00:00:51 2022
00:04 -!- codaraxis__ [~codaraxis@user/codaraxis] has joined #hplusroadmap
00:08 -!- codaraxis___ [~codaraxis@user/codaraxis] has quit [Ping timeout: 250 seconds]
00:23 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has quit [Quit: Leaving]
00:24 -!- alexbfi_ [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has quit [Quit: Leaving]
01:23 -!- spaceangel [~spaceange@ip-94-113-214-149.bb.vodafone.cz] has joined #hplusroadmap
01:25 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has quit [Ping timeout: 264 seconds]
02:58 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has joined #hplusroadmap
03:09 -!- codaraxis___ [~codaraxis@user/codaraxis] has joined #hplusroadmap
03:13 -!- codaraxis__ [~codaraxis@user/codaraxis] has quit [Ping timeout: 264 seconds]
04:02 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
04:22 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has quit [Remote host closed the connection]
04:50 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has joined #hplusroadmap
05:43 -!- cc0 [~cc0@2a01:4f9:c010:cf0b::1] has quit [Remote host closed the connection]
05:53 -!- cc0 [~cc0@2a01:4f9:c010:cf0b::1] has joined #hplusroadmap
05:56 -!- cc0 [~cc0@2a01:4f9:c010:cf0b::1] has quit [Remote host closed the connection]
05:58 -!- Llamamoe [~Llamamoe@178235178034.dynamic-4-waw-k-1-2-0.vectranet.pl] has joined #hplusroadmap
05:59 -!- cc0 [~cc0@2a01:4f9:c010:cf0b::1] has joined #hplusroadmap
06:23 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has quit [Quit: Leaving]
--- Log closed Tue Oct 18 06:49:04 2022
--- Log opened Tue Oct 18 06:49:04 2022
06:50 < kanzure> hmph
06:52 -!- yashgaroth [~ffffffff@2601:5c4:c780:6aa0::1909] has joined #hplusroadmap
08:02 < kanzure> jotmuch isn't python3 compatible :/
08:39 < muurkha> ugh
08:40 < muurkha> fenn: Baumol's cost disease?
08:40 < muurkha> or it might just be "collapse" ;)
09:02 -!- CVDFNSTR is now known as Mabel
09:32 < TMA> fenn: that cultural phenomenon is called progress
09:33 < TMA> (in the debased sense, but progress nevertheless)
09:41 < Mabel> something something about mistaking motion for progress
09:44 -!- Molly_Lucy [~Molly_Luc@user/Molly-Lucy/x-8688804] has joined #hplusroadmap
09:48 < Mabel> good question though, there has to be a word for it!
09:54 < Mabel> it has also been pointed out that the amount and complexity of laws and regulations grows over time, especially if they don't have expiry dates
10:02 < Mabel> https://youtu.be/OMm5AGZ1NVw?t=167
10:02 < Muaddib> [OMm5AGZ1NVw] Elon Musk: Best form of government on Mars | Lex Fridman Podcast Clips (7:27)
10:03 < maaku> lsneff: yes, I just don't know at what point I should raise money for it
10:03 < maaku> vs. bootstrapping
10:06 < heath> https://www.cshl.edu/research/faculty-staff/anthony-zador/#publications
10:06 < heath> https://www.nature.com/articles/s41587-020-0704-z RNA timestamps identify the age of single molecules in RNA sequencing
10:12 -!- mirage33515 [~mirage335@2a01:4f8:120:2361::1] has joined #hplusroadmap
10:12 < kanzure> wasn't zador one of the FISSEQ/DNA barcoding rosetta brain stuff people..
10:13 < kanzure> the professor of "just use DNA sequencing of neurons and barcodes instead of electron microscopy for brain scanning"
10:16 -!- mirage335 [~mirage335@2a01:4f8:120:2361::1] has quit [Ping timeout: 244 seconds]
10:21 < muurkha> Mabel: what does elmu think the best form of government on Mars is?
10:34 < Mabel> some form of direct democracy; laws must be short enough that people can understand them; absolute transparancy; garbage collection function for rules & regs; laws easier to repeal than to pass
10:37 < Mabel> (as of Dec 2021)
10:41 < muurkha> sounds pretty decent
10:42 < maaku> lsneff: tbh I don't know if now is a good time to raise money though 🤷‍
10:44 < maaku> Mabel: sounds decent. where'd he say that though?
10:48 < Mabel> https://www.youtube.com/watch?v=DxREm3s1scA&t=2479s
10:48 < Muaddib> [DxREm3s1scA] Elon Musk: SpaceX, Mars, Tesla Autopilot, Self-Driving, Robotics, and AI | Lex Fridman Podcast #252 (151:48)
11:18 -!- mirage3351552 [~mirage335@2a01:4f8:120:2361::1] has joined #hplusroadmap
11:22 -!- mirage33515 [~mirage335@2a01:4f8:120:2361::1] has quit [Ping timeout: 244 seconds]
11:23 < maaku> In a class so I'll have to watch later, but thanks!
11:44 < docl> the bit about the money database later in the talk is also interesting. I've lately been putting some thought into ways to design a money database that's less susceptible to information loss
11:50 < muurkha> you could pay people to prove on short notice that they knew parts of it
11:52 < muurkha> filecoin style
11:57 < L29Ah> pay a bit more to make them forget
12:00 < muurkha> given how irrational people are about dollar auctions, you might have to pay a lot more
12:00 < docl> well, there's securing the ledger integrity, but also managing how much money exists in it at a given time. my main idea for that is having a fluid currency that expands/contracts based on how efficiently people close the loop by regaining the amount they spent
12:00 < muurkha> also how can you prove you don't know something?
12:02 < muurkha> when I lived in Dallas the local radio station KVIL flew a helicopter over the highways at rush hour, looking for people with a KVIL bumper sticker
12:02 < docl> so there's the basic unit, coins, and the fluid unit, notes. all notes are borrowed and have to be returned by the end of the month or the leveraged coins get transferred out to people who have surplus notes. then the borrowing ratio is based on the rate at which 0 or less coins are lost this way
12:02 < L29Ah> docl: is it superior to a fixed-supply system?
12:03 < muurkha> when they spotted one, they would announce their license plate on the radio (for the rest of the day if necessary) until they called the station on the phone
12:03 < docl> yes because it's not deflationary, so you know spending will not carry opportunity costs based on scarcity
12:03 < muurkha> then they would give them something, I forget if it was money or swag
12:03 < L29Ah> docl: spending will always carry opportunity costs based on scarcity
12:04 < muurkha> docl: how do you prevent people from extending credit to each other?
12:04 < docl> it's better to buy stock and hire people instead of hodling
12:04 < L29Ah> since human effort itself is scarce
12:04 < L29Ah> is it?
12:04 < L29Ah> malinvestment is worse than hodling
12:05 < docl> muurkha: no need to do that, but they assume risks in so doing
12:05 < docl> yeah malinvestment is bad
12:05 < muurkha> docl: they increase the money supply in so doing
12:05 < docl> that's fine, the money supply should expand if risk goes down
12:06 < muurkha> I mean you might think this is a question of https://www.youtube.com/watch?v=CzvQxQYKO88 but actually it's quite a large effect
12:06 < Muaddib> [CzvQxQYKO88] Nanowar Of Steel - Tooth Fairy (Lyrics Video) [feat. Mario Draghi] (5:12)
12:06 < docl> the point of money is to measure risk, so it needs to grow/shrink on the basis of that
12:06 < L29Ah> and the more important point for a monetary system: does it incentivize using itself over a fixed-supply system?
12:07 < muurkha> hmm, in that case why isn't it enough to have a fixed supply of hard currency and have people extend credit as they feel is appropriate?
12:07 < L29Ah> e.g. why would anyone buy these tokens for their bitcoins just to see their value drop over time?
12:08 < docl> muurkha: extending credit is inherently risky because if anyone can grift a lender the total risk increases
12:09 < muurkha> yes, but doesn't that give lenders the proper incentives to measure risk the way you're describing?
12:09 < docl> the goal is for people to measure their own risks. it's hard / needs close surveillance to have a third party do it
12:10 < pasky> maaku: it's fine time to raise preseed / seed
12:11 < docl> so the fixed supply currency is distributed equally to everyone every monthly. say 1000 coins/month. then it all gets taxed back at the end of the year. the point is having something predictable to risk when you borrow the notes against it
12:13 < muurkha> 1000 coins per month per person?
12:13 < docl> some integer, doesn't really matter what you pick
12:14 < muurkha> how do you distinguish persons from unpersons?
12:14 < docl> the note rate is based on a combination of how many times you repay all your notes successfully and how often this happens across the network
12:20 < docl> I'm still working out the best approach to individual verification. the tax system works by letting people bid on land value with their coins, and everyone pays automatic rent to the winning bidder there. unused coins are used for a purchase in a share of all the land, so there's also a rent there. making good bids gives you positive cashflow in notes whereas not bidding or having a low year-end coin 
12:20 < docl> balance while residing in a place that attracts high bids tends to result in that being negative
12:21 < docl> the land value asset only lasts a year, which is where it goes from a generally-below-market investment to actual tax
12:22 < docl> I'm planning to do a real blog post later, but for now I've been putting it in an etherpad doc here http://moredoingstuff.com:9001/p/ACES
12:23 < muurkha> oh, I thought you were investigating designing a money database; I didn't realize it was a whole social-planning problem
12:24 < docl> not sure it's really distinguishable. reliable distributed ledgers are one thing, making a system people would benefit on net from using is a bit trickier
12:26 < muurkha> American Airlines and Ithaca, NY, seem to have deployed complementary currencies successfully without reforming the tax system, though certainly everything affects everything else
12:37 -!- mirage3351552 [~mirage335@2a01:4f8:120:2361::1] has quit [Quit: Client closed]
12:37 -!- mirage3351552 [~mirage335@2a01:4f8:120:2361::1] has joined #hplusroadmap
12:40 < docl> well, maybe not trickier but, it's it's own beast. interestingly the merkle tree aspect is already basic part of version control systems like fossil and (I think also) git. I'm thinking of setting up a testnet around the concept based on fossil as a learning exercise
12:44 < muurkha> git is pretty profoundly merkle-graph-based, yeah
13:00 < kanzure> docl: would you please spend a few cycles on how to computationally specify licensing fees for "open-source" software projects in a way that would make sense for ecosystems where packages have dozens of dependencies?
13:00 < kanzure> eg on what basis would revenue be shared or how would money flow without requiring manual negotiation by every n parties that use 100,000 different pieces of software
13:00 < muurkha> just give it all to whoever is most prestigious
13:01 < kanzure> and they divy it up?
13:02 < kanzure> like how exactly does one determine how much additional value a faster square root algorithm actually provides to a company making $20 billion/year from a diverse product portfolio built on top of "open-source" software
13:02 < muurkha> no, they just keep it
13:02 < kanzure> and what if that faster algorithm is actually burried 5 packages deep and there was never any contact between its author/the library and that company?
13:03 < kanzure> muurkha: that does not sound like a functional economy!
13:03 < muurkha> hey, it's how the humans do things, I don't make the rules
13:03 < muurkha> I just live here
13:03 < kanzure> part of the benefit of permissionless innovation and zero-friction licensing that open-source has is that you don't have to manually negotiate with thousands of software developers for use of their work
13:04 < kanzure> but so far that has come at the cost of unpaid labor or property
13:04 < muurkha> yeah, I think that's kind of inherent
13:04 < kanzure> and, until recently (with cryptocurrency), there was no plausible way for aggregating millions of micropayments together to package authors in large package ecosystems
13:04 < muurkha> yep
13:05 < kanzure> how do i take muurkha out of hidden markov model chatbot mode?
13:06 < muurkha> heh.  it's just that it's a problem that has no known solution, I'm just describing the things people do to deal with that
13:08 < kanzure> could have "agent software" negotiate on everyone's behalf
13:08 < kanzure> or an unpaid version of the ecosystem that has a licensing requirement of contributing popularity data upstream (cpu cycles, load, revenue, other information)
13:08 < kanzure> from which paid solutions might become obvious
13:09 < muurkha> if you update your library to use less CPU cycles, does that reduce your share of the revenue?
13:10 < kanzure> should it? or should it not?
13:10 < muurkha> well, generally it produces more value if it produces the same output in less CPU cycles
13:10 < muurkha> so from that sense it should not
13:11 < kanzure> the system doesn't need to extract maximum value, but it also has to extract enough value that it's not as bad as spotify payouts or just a few microcents over the years
13:11 < muurkha> it needs to not incentivize perverse behavior
13:12 < kanzure> well, if there is a lot of demand for an overpriced library, i think other developers will come in and try to make cheaper competitor libraries
13:12 < muurkha> how about if your library is a thin shim over a different library, and you add an inefficient caching layer that reduces the calls to that other library by 99%, but only reduces runtime by 20%?  now you've transferred 80% of the value to yourself
13:13 < kanzure> (i suppose that is not an example of a perverse behavior)
13:13 < muurkha> if you measure by CPU cycles
13:13 < muurkha> yeah, at that point you're just describing proprietary libraries though
13:13 < kanzure> yeah i think proprietary is ok here, it's just also "permissionless innovation" with contractually enforced payments
13:14 < kanzure> good example.
13:14 < muurkha> well, automatic micropayments would make proprietary libraries less painful to use, it's true
13:15 < kanzure> i think that people would compete to make more efficient cheaper caching layers, in your scenario
13:15 < muurkha> maybe, but if the library you're layering on top of is efficient enough, it may be hard to make much progress that way
13:16 < kanzure> i don't know a lot about proprietary library pricing models... usually i just see per CPU core, per seat, flat annual fee, flat one-time fee, adware, paid support, etc
13:17 < muurkha> there was a lot of enthusiasm in the 90s about software component markets enabled by object-oriented reuse
13:17 < muurkha> that's what Brad Cox invented Objective-C for IIRC
13:17 < kanzure> yeah DCE/RPC/DCOM was some serious castle-in-the-sky stuff
13:17 < kanzure> .wik DCE/RPC
13:17 < saxo> "DCE/RPC, short for 'Distributed Computing Environment / Remote Procedure Calls', is the remote procedure call system developed for the Distributed Computing Environment (DCE).  This system allows programmers to write distributed software as if it were all working on the same [...]" - https://en.wikipedia.org/wiki/DCE/RPC
13:18 < kanzure> .wik distributed component object model
13:18 < saxo> "Distributed Component Object Model (DCOM) is a proprietary Microsoft technology for communication between software components on networked computers." - https://en.wikipedia.org/wiki/Distributed_component_object_model
13:18 < muurkha> COM (but not DCOM) did achieve a significant degree of software-component-market success
13:18 < muurkha> I don't know exactly what the relationship between COM and VBX was, but I think maybe COM started as the VBX interface
13:18 < muurkha> and for a while there was a thriving market in VBXes, later OCXes
13:19 < muurkha> but nothing approaching what you see in create-react-app
13:20 < kanzure> a paid ecosystem could be made around a simple flat fee model: license requires you to pay $x as a one-time fee once you surpass $y in revenue, central org to audit every company that signs up for the ecosystem
13:21 < muurkha> yeah, but you still have the problem of attributing the company's value to the various software providers
13:21 < kanzure> ideally there would be a way for people to specify novel cost negotiation schemes that can be put into automated software, and then the beginning of the ecosystem doesn't have to specify it or solve the whole problem
13:21 < kanzure> not sure i understand
13:22 < kanzure> if it's a one-time fee like $100 for libzkproofs per company that has at least $1m/year in revenue, then a central org audits the companies and bills 'em
13:22 < kanzure> (also, the company would be unable to use software in this ecosystem without agreeing to that kind of audit, and developers would be incentivized to whistleblow)
13:23 < muurkha> your example of a faster square root algorithm; how can you know what the company's earnings would be without that algorithm?  what if there are two different software components which are both necessary for the company to remain profitable?
13:23 < muurkha> this is a problem with employment too
13:23 < kanzure> in my current proposal i am just saying the library authors set a flat fee to use their library, payable upon passing a certain revenue threshold
13:23 < kanzure> and yes this won't necessarily capture all the value created by using a faster square root, but it will capture non-zero value at least
13:23 < muurkha> true
13:24 < muurkha> it won't be very good at price discrimination though
13:24 < kanzure> and it has the additional property of being simple to describe and imagine (compared to CPU cycle counting)
13:25 < muurkha> yes, and it doesn't incentivize you to sandbag
13:25 < kanzure> sandbag?
13:25 < muurkha> make your software consume more resources than necessary in order to increase your earnings
13:25 < kanzure> we shall fondly call this project "embraceum" in honor of microsoft
13:27 < kanzure> yeah maybe the options could be: a PAYME file next to the LICENSE file, and inside can be either a one-time fee after some company threshold, or an annual fee after some company threshold. a DSL or configuration format can allow for novel strategies to be declared and parsed by ecosystem-compatible tooling.
13:27 < kanzure> library maintainers can update the PAYME file through merges to reflect relative proportional payouts to authors on their project's team to be paid accordingly to their value or whatever other agreement they came to
13:29 < muurkha> presumably packagers like Red Hat would update all the PAYME files to point to them, if the license permitted it
13:29 < kanzure> surely the license should not permit this.
13:29 < kanzure> lawyers hate this one simple trick
13:29 < kanzure> s/simple/weird
13:29 < heath> kanzure: yeah. in the the toasters and molecular ticker tapes paper, zador is referenced as that guy
13:32 < muurkha> right, but if the license doesn't permit it, you effectively can't fork a project.  or you can but the payments still go back to the original author
13:32 < kanzure> forks would require negotiation with the project maintainer, i would think.
13:33 < kanzure> or that, yes.
13:34 < muurkha> I expect to see embraceum collapse in a acrimonious festival of accusations and counter-accusations like an estranged Argentine family suing one another over their inheritance once their parents die
13:35 < muurkha> which is fine as long as people don't confuse it with open source I guess
13:36 < kanzure> oh i didn't know USDOJ uncovered "embrace, extend, extinguish" from internal microsoft emails, hah
13:36 < muurkha> haha, I hadn't heard that either
13:45 < kanzure> i don't know, how much value have the libc authors generated? or how much of that value was because they didn't do any value extraction at all?
13:50 < muurkha> I think the authors of libc and its counterparts (the STL and the rest of the C++ standard library, the standard libraries of Python, Golang, etc.) have totally transformed software development over the last 30 years, to the point that people commonly complain about coding interviews that ask them about things that are in their view only of academic interest
13:51 < muurkha> because they're in libc
13:52 < muurkha> but there isn't an obviously correct way to apportion the value of the modern software ecosystem even among library authors and application authors
13:52 < muurkha> libraries are worthless without applications, and applications are 
13:52 < muurkha> harder to write without libraries, sometimes by orders of magnitude
13:54 < muurkha> a consequence of this is that the vast majority of modern applications would have been uneconomic to write without libraries
13:54 < kanzure> there ought to be a way of providing mechanisms for allocating and distributing value without having to centrally plan what the actual value calculations are required to be
13:54 < muurkha> the epitome of this is probably something like xshostakovich
13:55 < muurkha> which points out that most of those applications are of very little value
13:55 < kanzure> ? https://www.lcdf.org/xshostakovich/
13:55 < muurkha> yes
14:07 < kanzure> could also have a centrag org that creates 'shares' (tokens) that then can be attached to libraries for certain revenue from collection activities... not sure how that would work.
14:21 < muurkha> they would probably be apportioned according to social prestige, regardless of how you intended it to work
14:25 < kanzure> hmph
14:36 < kanzure> https://ciechanow.ski/mechanical-watch/
14:57 -!- Molly_Lucy [~Molly_Luc@user/Molly-Lucy/x-8688804] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:03 -!- faceface [~faceface@user/faceface] has quit [Ping timeout: 264 seconds]
15:21 < kanzure> https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c
15:22 < muurkha> yeah, there are a bunch of interesting proposed mechanisms for public goods funding, and some of them are sound
15:26 < muurkha> but it seems like Vitalik is not really attacking the hard parts of the problem, which are (a) how do you get users to put funds into the pot and (b) how do you choose which projects have been valuable
15:27 < muurkha> he's only solving (c) how do you escrow the paid-in funds and then transfer those funds to the selected awardees
15:28 < muurkha> which, well, has often been solved by Trent with relatively minimal levels of corruption in the administration, even though yes a DAO could be better and more transparent
15:29 < kanzure> it seems unlikely that oracle and microsoft are already extracting maximum value from their software sales
15:30 < muurkha> well, and I guess he's proposing that if people sell shares of their possible future awards, that could help, but I think that will take awhile to materialize
15:30 < muurkha> but the much bigger problem is how you choose the awardees and how you avoid the free-rider equilibrium
15:31 < muurkha> dominant assurance contracts are an interesting approach to the second
15:35 < L29Ah> https://wisqars.cdc.gov/data/lcd/home
15:35 < L29Ah> are there similar tables for some other populations?
15:35 < kanzure> i like the idea of a project's maintainers pgp signing off on payment terms and then checking that all packages are signed
15:35 < L29Ah> .de/.fr/.ja would be especially interesting
15:35 < L29Ah> as usanians are notoriously obese
15:36 < muurkha> L29Ah: I would also be very interested!
15:36 < muurkha> assuming you mean .jp
15:37 < L29Ah> yes
15:38 < maaku> pasky: will it be a fine time to raise a series A 9-15 months later?
15:40 < kanzure> strong execution on great ideas can get funded whenever
15:40 < pasky> maaku: unlikely unless your growth is amazing; you need to plan for slower burn (but that can be a good thing too, there's less pressure for quick growth and you can take more shots at it)
15:41 < maaku> yeah this is a long play and it might be a while until there's revenue, let alone break-even
15:41 < pasky> strong execution on great ideas is easier said than done at seed stage, esp. for first time founders :)
15:42 < maaku> this would be my second
15:42 < pasky> maaku: ok but then series a isn't your concern, is it?
15:43 -!- spaceangel [~spaceange@ip-94-113-214-149.bb.vodafone.cz] has quit [Remote host closed the connection]
15:43 < pasky> oh nice; i sometimes wonder what exciting completely different mistakes (and what of the same mistakes) i'd do in my second pass :)
15:44 < maaku> I think I have 3 options here: (1) bootstrap; (2) ~10 employees for 5-10 years, then growth; or (3) 100+ employees, full APM in 5 years
15:45 < maaku> all 3 options are compabible with the idea.. I just want to avoid choosing the wrong path and not being able to get funding at a key time and have it all fall apart for that reason
15:45 < maaku> and I really have no clue what the current recession (or whatever you want to call it) and Ukrain + Taiwan tensions are doing to the VC market
15:45 < kanzure> if you can demonstrate functioning atomically precise manufacturing then i think you can raise any amount you want
15:45 < maaku> plus I despise VCs with a passion
15:46 < kanzure> on the other hand, R&D is a very different fundraising story
15:46 < maaku> kanzure: no, it's the patent pool idea which foregoes the need to solve finicky hardware problems
15:47 < pasky> maaku: wait what exactly do you mean by an APM? (do you have it written down anywhere what exactly would you like to build?)
15:47 < maaku> although if I could raise blockstream levels of funding for a quick series of rounds, maybe the direct-to-APM approach would make sense
15:47 < pasky> product is only part of the story, early market validation is as important
15:47 < pasky> sounds like you want to build something really big
15:48 < kanzure> i think maaku's last company raised a total of $200m or something
15:49 < maaku> At least for the time I was there. I think they're over $300-400M raised on a $4b valuation now? I'm not sure
15:49 < kanzure> eh who knows such things, just a mystery i guess *shrug*
15:50 < pasky> Oh nice. What's the company name if you can share? Were you a cofounder, board level?
15:50 < maaku> But then I wasn't in the room with investors at any point, so it's not like I have much relevant direct experience with that aspect of fundraising
15:50 < maaku> I was a founder at Blockstream
15:50 < pasky> oic
15:50 < maaku> https://blockstream.com
15:51 < maaku> left in 2018
15:53 < maaku> pasky: The idea's not that complicated, and some ppl here know about it. Basically I want to fund drexlarian molecular nanotechnology via financial engineering.
15:53 < pasky> must have been a fun ride! (if the culture was good)
15:54 < maaku> I've got some ideas for making a marketplace around nanotechnology patents, and using that to drive a hype cycle of investment like we see in crypto-space
15:54 < maaku> If that works, it'll fund the larger endevour of actually making the atomically precise manufacturing process.
15:55 < maaku> If it doesn't... well, we'd at least have an open-source CAD/CAM environment for APM
15:55 < pasky> so kickstarter+thingiverse at nanoscale? :)
15:57 < maaku> Maybe that works to get the idea across, but it's more targeting institutional speculators and/or professionals than the direct-to-consumer model of kickstarter
15:57 < pasky> that sounds pretty cool! super risky too but why do you need 100 people to build this? an MVP should be very lean, no? what's the big chunk of the work if you are just the middleman
15:57 < pasky> yeah I understand, of course not b2c and you are getting patents, not finished products, right?
15:57 < maaku> you might have to be an accredited investor to use the platform (or a principal engineer)
15:58 < maaku> If you invent a new planetary gear or something, we would provide a pipeline for getting it patented, and a patent pool that might buy it
16:05 < pasky> Hmm I'd have so many questions about this. I'd encourage you to write your vision down, it might be helpful for your thinking and evaluating various plans too.
16:09 < pasky> (I might be missing a lot of things and not sure if I grok the whole vision, but so far my main doubt is the core idea - if I get it right - that you'll support big pools on the buyer side that will at some point overcome the critical mass to actually make APM commercially feasible. In an ideal world of efficient markets, it could make sense. But in reality I worry ideas go to patent pools to die 
16:09 < pasky> because it's not where great operators go. Are there ...
16:09 < pasky> ... any success stories outside of nanotech of this working? And are there any existing potential buyers in the nanotech space yet?)
16:14 < pasky> Of course you could go CAD+CAM first, a sort of gamified idea could also work rather than going marketplace-first. You have a virtual simulation where you play around with things, once they work, *you* offer to buy it, say flat fee + x% of revenue (normalized per surface area or whatever). You could have a bunch of geeks playing around finding cool designs and making pizza money. (At that point, maybe 
16:14 < pasky> a RL agent could do a better job though?)
16:15 < pasky> Of course I know so little about the space. Is the lack of good building blocks really the main blocker? Are there well known backlogs of awesome nanotech stuff we'd love to build if we only knew how to design it? I thought the main blocker is the APM process, not designs.
16:16 < pasky> (I wonder if there's some analogy with quantum computing. Three problems - algorithms, hardware and applications. We don't yet know how to build good hardware, and we also don't have any interesting algorithms besides annealing and shor yet (I guess?))
16:17 < maaku> pasky: yeah this ain't your ganddaddy's patent pool. it's twisting patent to achieve a positive outcome instead of collecting rent
16:18 < maaku> although it does necessarily involve some rent collection after APM is realized.. but that's a small price to pay for such a transformative technology
16:19 < maaku> it's kinda how some biotech companies operate: invent a drug or discover a gene, patent it, and then sell the company holding the patent to big pharma
16:19 < maaku> except big pharma does exist in this case, so instead the pool itself is patent-holder owned, with a constant annual dillution that is used to buy up the most promising patents
16:20 < maaku> which means there'd be a secondary market for buying and selling shares of LLCs owning patents whose value is speculative
16:21 < maaku> in operation it is closer to the way mining claims are traded on some of the british columbia speculative exchanges
16:21 < maaku> but if I could raise $100M or more ... it probably makes sense to just skip all this and go straight to making APM
16:23 < maaku> "a bunch of geeks playing around and making pizza money" is exactly how it would start though; that's the idea
16:23 < maaku> the pizza money here would be shares in a patent pool for nanotechnology, which from a trad economics standpoint is worthless if APM is further off than the time horizon of the patent
16:24 < maaku> but as time goes by the patent pool gets bigger, de-risking the basic idea and bringing APM closer to fruition, so shares of the patent pool trade higher, in a positive feedback loop
16:25 < maaku> what I need now though is people to work on the APM CAD/CAM environment, and people cost money, hence looking at what kind of seed + series A would be achievable
16:28 < maaku> also if this interests any lurkers here, PM me
16:29 < pasky> I'm trying to figure out why existence of these pools makes APM more likely to exist. It's not obvious to me. Ok, people who patented some nanotech components have shares in the pool are incentivized to build APM to profit off these patents. But they might not have that many resources for that, if they are just geeks messing around. And for everyone else, it might be super tempting to actually hold 
16:29 < pasky> off investment until the patents expire?
16:32 < maaku> Not existence of the pools, but rather the patents themselves. Or rather still, the designs contained within the patents.
16:33 < maaku> The idea is to (1) build up a design overhang, in that there are tons of licensable things to build right of the bat if you can get APM working; and (2) build up the toolbox of things you'd actually need to get APM working too
16:33 < maaku> That makes APM more likely, on shorter horizons, and that gives the patent pool value.
16:34 < maaku> Plus the pool is growing and accepting new patents every year, so it's not like the whole thing expires.
16:34 -!- Gooberpatrol66 [~Gooberpat@user/gooberpatrol66] has quit [Remote host closed the connection]
16:34 < maaku> The MPEG-2 patent pool is still licensed by Apple and Qualcomm, despite it being more than 20 years since MPEG-2 was released
16:35  * kanzure raises his hand
16:35 < kanzure> hi, yes, but isn't the MPEG consortium completely evil?
16:35 < maaku> excellent question!
16:35 < maaku> Yes, and I'd go a step further and say all forms of rent collection are inherently evil.
16:36 < maaku> However if this can make APM happen on a shorter time horizon than it would otherwise, then I think that can be a net benefit. Hate the short-termism in the financial markets that makes finding other means to fundraise APM difficult.
16:37 < maaku> And also, the patent pool would have an open, fair minimally restricted license model under standard, affordable terms
16:38 < L29Ah> muurkha: the best data aggregator for multiple countries of interest i found so far (skip covid): https://www.worldlifeexpectancy.com/country-health-profile/japan
16:38 < L29Ah> interestingly, i couldn't find decent visualizations at WHO itself
16:40 < pasky> maaku: I see. This self-reinforcing principle does make sense to me, nice. Also it's obvious I guess but I didn't realize that these patents can also help make APM itself.
16:42 < pasky> Any idea how many nanotech patents exist right now? (How many nanotech device *designs* exist right now? Hundreds? Tens of thousands?)
16:43 < kanzure> https://github.com/kanzure/nanoengineer has a few visualizations of some of the structures proposed in drexler's nanosystems book
16:44 < muurkha> L29Ah: thanks!
16:44 < muurkha> I wonder if the patent pool would have a chilling effect on the development of free software for APM designs
16:45 < pasky> pretty!
16:45 < pasky> ok so that lower bounds the number on tens :)
16:46 < L29Ah> https://github.com/kanzure/nanoengineer#1-gallery i wonder at what temperature range do these function
16:46 < L29Ah> the fact that there's some wobbling suggests that temperature is included in the model
16:47 < muurkha> also though can you actually get patents on things that are currently impossible to build? I thought you couldn't
16:47 < muurkha> like, the patent has to contain enough information for one reasonably skilled in the art to practice it
16:47 < pasky> muurkha: I believe it happens all the time
16:47 < muurkha> doesn't that exclude patents that can't actually be practiced yet?
16:49 < maaku> pasky: the most famous patent is probably the Merkle-Freitas diamond tooltip patent : http://www.molecularassembler.com/Papers/MinToolset.pdf
16:49 < maaku> those two guys have a few other patents... beyond that, I don't know. Not many, I would imagine
16:50 < maaku> but one of the many things I hope to provide is a searchable databse of designs, new and old
16:53 < pasky> oh wait is it *that* Merkle?
16:53 < maaku> yes
16:53 < pasky> I should read up more about nanotech
16:54 < maaku> they're now involved with a secretive canadian effort to make APM
16:54 < docl> still reading the backlog. I think my system has room for a public works funding mechanism. it kind of needs one if it wants to fund roads and such anyway. I'll keep thinking about it
16:55 < maaku> pasky: have you read Radical Abundance? it's probably the best introuctory level book, although aimed at a general audience, and up to date with more recent advanced in biotech and manufacturing
16:55 < maaku> almost a decade old at this point tho
16:58 < pasky> no I didn't, thanks - free sample already in my kindle app now :)
16:59 < pasky> I'll do some reading, thanks for the inspiration.
17:00 < pasky> It still feels many ways should be possible to bootstrap your concept in a lean way. But maybe I'm just not appreciating the realities of this yet.
17:01 < kanzure> pasky: i knew about merkle because of his involvement in cryonics, nanotech and transhumanism; it's everyone else that mistakeningly knows him only for inventing modern cryptography!
17:08 < maaku> pasky: there are some things to check out here: http://www.molecularassembler.com/Nanofactory/
17:08 < maaku> and here: http://www.molecularassembler.com
17:09 < maaku> the nanomedicine books were nice about medical applications as well
17:09 < muurkha> well, he invented modern cryptography first
17:15 < kanzure> http://web.archive.org/web/20070311022139/http://www.itas.fzk.de/mahp/weber/merkle.htm
17:15 < kanzure> at 21:39 https://gnusha.org/logs/2015-09-06.log
17:16 < kanzure> on an unrelated note, it would be interesting if there was a way to cryptographically hide your thoughts from god
17:17 < kanzure> and, on that note, why would god ever need a backdoor to be installed in public cryptography systems?
17:17 < kanzure> andrew was mentioning indistinguishability obfuscation as one potential route for that
17:17 < muurkha> this reminds me of some notes I found on a shared host
17:18 < maaku> is your god onipotent?
17:18 < kanzure> unspecified; luke-jr was not amused by any of this but he was a good sport listening to me praddle on.
17:18 < muurkha> they said:
17:18 < muurkha> OH CR*P IM BEING REPORTED !!!!
17:18 < muurkha> I HATE THE ANTICHRIST
17:18 < muurkha> I HATE THE ANTICHRIST
17:18 < muurkha> I HATE THE ANTICHRIST
17:19 < maaku> yeah the christian god (most if not all denominations, certainly catholic) that would be an axiomatic impossibility
17:19 < muurkha> the user in question then logged off and never returned
17:19 < maaku> *for the christian god
17:19 < docl> the catholic one, if we are discussing luke-jr
17:21 < maaku> for luke I'm sure the "christian god" and "catholic god" are the same thing, lol
17:21 < muurkha> maaku: did the concern about chilling effects make sense?
17:21 < maaku> kanzure: you at a bitcoin meetup or something?
17:21 < kanzure> maaku: spent last week in atlanta https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/ and https://diyhpl.us/wiki/transcripts/tabconf/2022/
17:22 < maaku> muurkha: I missed your question. thank you. I would like to structure the standard license agreements to be FOSS-friendly
17:22 < maaku> to actually manufacture the thing would require paying royalties, but no restriction on sharing designs
17:23 < muurkha> well, there are two possible problems there, one legal and one morale
17:23 < muurkha> legal problem is that some patents might read on software implementations
17:24 < kanzure> i don't believe in moral problems, only moral solutions
17:24 < muurkha> not moral, morale
17:24 < kanzure> (trolley intensifies)
17:24 < kanzure> ah, alright, fine.
17:24 < muurkha> morale problem is that people might find it dispiriting to think that they're donating free software to the commons so that the patent pool can privatize it once it's profitable
17:26 < muurkha> RAND or FRAND terms would satisfy some potential contributors, but as kanzure pointed out with his remarks about the MPEG-2 consortium, possibly not many
17:28 < kanzure> i should note that i'm a big fan of almost any attempt to get us to molecular nanotechnology and APM
17:29 < kanzure> even if you have to use intellectual property to do so
17:42 < maaku> RAND or FRAND terms?
17:43 < maaku> And I'm in agreement with kanzure. A future where we have APM on a short timeline, but encumbered by patents is vastly better than a future where we don't have APM at all.
17:44 < maaku> And so long as patents exist (I would prefer that they didn't), we will have to deal with them.
17:44 < maaku> Might as well setup a patent pool with fair and reasonable standard licensing open to all
17:44 < maaku> Instead of letting Intellectual Ventures capture all the imortant patents
18:09 < muurkha> I don't think you have to let Intellectual Ventures do anything at all if you have APM
18:29 -!- Gooberpatrol66 [~Gooberpat@user/gooberpatrol66] has joined #hplusroadmap
18:30 < maaku> I don't follow.
18:35 < maaku> I love how Merkle came up with public key cryptography for a class project and the professor was like "No, that's dumb. Do a data compression thing instead."
18:38 < maaku> Well that professor was Hoffman, so I guess it makes sense.
19:05 < muurkha> Huffman?
19:10 -!- darkdarsie [~darsie@84-113-55-200.cable.dynamic.surfer.at] has quit [Ping timeout: 264 seconds]
19:14 < kanzure> pretty cool that legit hacking devices were marketed to kids in the 90s https://en.wikipedia.org/wiki/GameShark
19:21 < maaku> muurkha: yeah wrong prof, oops
19:22 < muurkha> the story of the invention of huffman coding is pretty amusing.  Dantzigesque
20:13 -!- yashgaroth [~ffffffff@2601:5c4:c780:6aa0::1909] has quit [Quit: Leaving]
20:48 -!- Netsplit *.net <-> *.split quits: saxo, srk, lsneff, catalase, luna_
20:48 -!- Netsplit over, joins: saxo
20:50 -!- Netsplit over, joins: catalase
20:51 -!- lsneff [~lsneff@2001:470:69fc:105::1eaf] has joined #hplusroadmap
20:51 -!- srk [~sorki@user/srk] has joined #hplusroadmap
20:52 -!- Mabel [~Malvolio@idlerpg/player/Malvolio] has quit [Ping timeout: 264 seconds]
21:00 -!- Malvolio [~Malvolio@idlerpg/player/Malvolio] has joined #hplusroadmap
21:35 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has joined #hplusroadmap
21:36 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has quit [Remote host closed the connection]
22:04 -!- Hooloovoo [~Hooloovoo@hax0rbana.org] has quit [Ping timeout: 252 seconds]
22:52 -!- alexbfi [~alexbfi@dzy9b2yypwzmq353lw3bt-3.rev.dnainternet.fi] has joined #hplusroadmap
22:54 -!- Hooloovoo [~Hooloovoo@216.169.5.238] has joined #hplusroadmap
23:37 -!- Hooloovoo [~Hooloovoo@216.169.5.238] has quit [Ping timeout: 268 seconds]
23:44 -!- Hooloovoo [~Hooloovoo@hax0rbana.org] has joined #hplusroadmap
--- Log closed Wed Oct 19 00:00:52 2022