SebRollen

Yeah, it's a good question, let me know if you figure out a good answer :)

Honestly, my focus right now is to make the site useful rather than profitable. This is a side-project that spawned out of needing something like this for my own research, so haven't figured out how/if I'll monetize it yet. The one idea I have related to the graph structure that I think could be valuable right now is letting users "subscribe" to particular sections of the law, with alerts for when there are new bills in Congress that might affect or alter it. The graph currently goes from bills > public laws > USC > CFR, so users could monitor a regulation and get notified as a bill moves its way through congress

Thanks! The primary goal is to make it the best place to research US federal law. All the features I have currently (cross-corpus search, version diffing, backlinks, law lineage, etc) will stay free and open.

Audience is primarily lawyers and legal researchers in fields that rely heavily on statutory law (tax, bankrupty, immigration, etc). I'm blessed to have a plethora of lawyers in my family/friends, so planning on using them as ~guinea pigs~ beta testers. If you (or anyone else reading this) think this is something you might use, I would love to talk more! seb@uscodex.org

In terms of monetization, I'm not really sure yet. My hosting costs are very cheap at the moment, so I'm not in any rush there, but I'm imagining I'll build in some more premium features like an API (for other legal-techs), change monitoring (for anyone relying on specific statutes in their work) or team research features (shared bookmarks, notes, collections etc). Open to suggestions here too! One very cool thing about my data pipeline is I've essentially built a connected graph of federal law with tens of millions of edges across millions across hundreds of thousands of sections, and I think there will be a lot of powerful applications of that dataset

Thanks! Super interested in hearing more about some of the battle-scars you've acquired from working in the space if you're open to sharing? Very early in the journey here, so still have a ton to learn!

So far, it seems like the federal space is relatively well-behaved compared to your experience with states. Most agencies standardized on the USLM schema[^1][^2] in 2013. Before that, it's a hodge-podge of XML and plain-text sources.

Also, FWIW, my interactions with federal agencies so far have been insanely positive. When I reported the error I found in the US code at 9pm, a staffer from the OLRC verified the issue and got back to me by 7am the next day, more efficient than most private sector organization's I've interacted with!

[^1]: https://github.com/usgpo/uslm.

[^2]: Meta: The USLM itself was created by federal law https://uscodex.org/usc/2/181

Aw, thanks! I thunk it myself :)

The cross-referencing between different corpora has actually been very helpful. I was able to find a typo in the notes to a US Code section through it and submitted it to the OLRC. They fixed it, so now I will forever be bragging about having fixed an error in the US Code haha

I'm building https://uscodex.org. In a nutshell, the goal is to collect all US federal law in version control, and cross-link any references between different sections. Currently I have the US Code, CFR, ~30 years of public laws and congressional bills and 25 years of executive orders.

Actually using raw git repos as the main data store which has worked out great since the US Code changes very little between new releases and so it compresses very well. Also makes it easy to generate diffs of sections: https://uscodex.org/usc/d/119-100/119-102not101/16/2201

They're talking about the font on the shirt

Kind of makes me wonder if the "more than 1,100 employees globally" actually means "1,111" employees. Talk about committing to the bit

About 1,200 kWh per transaction, currently[0]. I wrote about this back in 2022, when it was about 2,200 kWh per transaction[1].

Edit: made a chart with this data, but adding in a bitcoin transaction[2]

[0]: https://digiconomist.net/bitcoin-energy-consumption

[1]: https://rollen.io/blog/crypto-climate/

[2]: https://imgur.com/a/ggAGylW

Do you have an API?

The constant "By the way..." from Alexa drove me nuts.

If you say "Alexa, stop by the way", it'll get the device to stop responding with follow-ups for ~24h. I ended up creating a routine that runs every night at 4am to lower the volume to zero, automatically say "stop by the way" to the device, and then raise the volume a minute later, and Alexa has stopped with the follow ups

I've been tickled by the idea of a follow-up version, Send Me To Hell, where users instead throw their phones _downward_. High scores are awarded based on the maximum speed achieved as the phone hits the ground.

The second example for each language sample where the generated squid ends up being “B4aajs” essentially reads as “P0ooop” to a Swedish speaker.

Which is fine, they don’t propose to filter “bad” words in other languages, but kind of funny when that’s one of the highlighted examples, right next to the goal of filtering words. Goes to show how hard it is to filter profanity generally for international audiences

EDIT: My reply below is wrong - you _can_ deal with in-flight requests with E-Tags as well using the if-match header. I had only seen them used with if-none-match. TIL.

E-Tags would probably not help here, because the client won't have a tag to send along with its request until after the original response returns. But the thing we're trying to prevent in the first place is multiple concurrent requests being processed.

The Idempotency-Key header[1] is probably a better fit, but that relies on the server implementing the spec, including properly dealing with multiple in-flight requests with the same header. I found this blog post[2] pretty good for exploring some of the implementation challenges.

[1]: https://www.ietf.org/archive/id/draft-ietf-httpapi-idempoten....

[2]: http://live.julik.nl/2021/12/actually-creating-a-gem-for-ide...

The Common Paper app[1], though not quite a git workflow, has always struck me as being pretty close to how an software engineer might approach contracts:

1. An immutable set of standard terms, with variable references.

2. A collection of cover page variables, that modify the standard terms by reference.

3. A structured negotiation workflow, where users "propose changes" to the cover page variables with automatic "diff-ing" (redlining).

It's not a product targeted to software engineers, but has always appealed to me as a way to sneak in some engineering best-practices into the world of lawyering :)

Full disclosure: I'm an employee

[1]: https://commonpaper.com/product/

A few fun ones from finance:

https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...

http://www.thierry-roncalli.com/download/smart-beta-minimum-...

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3211951

Betterment's Cash Reserve[1] might be of interest to you. It's a similar concept, where they spread your deposits among multiple program banks to give you a higher level of FDIC insurance.

[1]: https://www.betterment.com/cash-reserve

I managed to get my rocket very very slowly rotating (<0.1° / s), so that I could just hold the acceleration and have it do one arc from launch to crash:

    Unbelievable, the crater is visible from Earth

    Score: 1712.2 point crash
    Speed: 15226.2mph
    Angle: 174.3°
    Time: 5963 seconds
    Flips: 0
    Max speed: 15226.2mph
    Max height: 1993862ft
    Engine used: 21 times
    Boosters used: 14 times
    https://ehmorris.com/lander/

RoQR: https://roqr.app/

It's a privacy-focused dynamic QR code application. Just got my first paying customer this past week, which I'm pretty stoked about!

The costs of running it are very low (~$15 / month), and it's not something I'm planning on ever turning into my main gig, but the fact that someone is willing to pay for an app I built on my own feels really fun

I'm building an open-source[1] alternative to qr-code-generator (Bitly), called RoQR[2]. The goal is to provide advertisers with analytics for the scans of their QR codes while still being as privacy-respecting as possible to the scanners of the codes - sort of like a Plausible.io for QR codes.

[1]: https://github.com/roqr/roqr [2]: https://roqr.app

No, the calculation is done per transaction, not per block. You can calculate the per-block consumption pretty easily based on the stat that there are about 150[1] blocks mined daily and the total TWh used per year for the network is 200[2]. 200 TWh per year / (365 days * 150 blocks) = 3.6MWh per block. The amount of transactions per block is around 2,000[3], so if you divide that number by 2,000 you get around 1,800 kWh per transaction

[1] https://stats.buybitcoinworldwide.com/blocks-daily/ [2] https://digiconomist.net/bitcoin-energy-consumption/ [3] https://ycharts.com/indicators/bitcoin_average_transactions_...

I think this commenter put it pretty well, so I'll just link to it: https://news.ycombinator.com/item?id=31596781

You're right that the energy cost is incurred at the block-level, but since each block can hold a certain number of transactions, you can then infer what the effective cost is per transaction. The source for kWh per transaction comes from Digiconomist's bitcoin energy consumption index, and you can find their methodology here: https://digiconomist.net/bitcoin-energy-consumption#assumpti...