That's a bummer. I wish there was a way to use non primitive objects in Maps & Sets more effectively then. Perhaps a well known Symbol for hashCode or something.

Are all strings under a certain length interned?

I wish Google Sheets supported a REST API for their new tables feature so you could interact with them more like a database and less like a 2D array

You could more or less achieve this, by using a Google Apps Script that exposes the sheet. I found spreadapi to be good enough for basic use.

https://github.com/ziolko/spreadapi

This is great, thanks!

I tried to export my Timeline history but I cannot get the full version. My Pixel 8 has the full version but no way to export. My iPhone does have a way to export but does not have the full version.

I still wish GMail supported deleting attachments without deleting the whole email.

I'm curious why they specify the UUID must have dashes in string format. It makes the UUID difficult to select with a double click.

As with IP addresses, UX/DX is not the primary concern

Try a triple-click.

probably because the dashes have semantic meaning

you do understand that they existed way before the mouse and button became the norm ?

I think widespread mouse usage and early uuid usage was similar in time, 1980's to early 1990's.

Not sure when the "doucle-click to select" UI paradigm became common though.

I had no idea that you could use the mailto: URL for a form action.

Same. How would that work? What would be the end result (email body)?

It passes all form fields in URL encoded format in the body (example, name=Billy+Cravens&state=TX)

Sounds like a really bad UX

I think if my mom was trying to submit a form, and it opened her email client with a body consisting of URL encoded data she’d probably just close the email client thinking that something went wrong. Then she’d try again and the same thing would happen again. Then she might call me, and I’d probably tell her to just forget about it and try to call them on the phone instead or give up and try another company instead.

> with a body consisting of URL encoded data

The e-mail client decodes the URL encoded data. So you actually see plain text. The encoding is only done for the purpose of passing the data from the browser to the e-mail client.

I created a form with a dropdown and a some other inputs.

The result when using enctype=application/x-www-form-urlencoded and method=post in the form html is that the body that is shown in my email client is URL encoded.

They have a different enc type that you could use to specifically make it plain text. That one is not recommended because then you're gonna have a bad time parsing out the fields that were submitted from the form.

And for reference, here is what the mail body looks like with enctype=text/plain and method=post when it is opened in iCloud mail ready to send

    cat=services
    btext=adsfasdfsdafsdf afsdfas asd fa sdf as dfs
    subscribe-newsletter-weekly-yes=yes

Other email clients might create different looking body for text/plain enc type.

One variant that seemed interesting was method=get with enctype=application/x-www-form-urlencoded

In this case the values from the form get added as headers in the email so they are not directly visible to the user

I thought that I could still add user-visible subject and body by adding ?subject=foo&body=bar to the mailto: url

For example I could then have the subject say "Web form submission", and have the body of the mail contain a description that tells the user to send the email and that the data they filled into the form will be sent along with the email.

Even that is not great UX imo, but could still be interesting.

However from my testing with Brave web browser and Apple Mail, the subject and body are not filled in for the user in this case.

Looks like it can also be plaintext encoded[1], so something like:

    name=Billy%20Cravens
    state=TX

[1]: https://html.spec.whatwg.org/multipage/form-control-infrastr...

Email body is in the “body” form field, subject line in “subject”, destination in “email”.

https://www.w3docs.com/snippets/html/how-to-create-mailto-fo...

Those parameters need to be passed in the mailto: URL, not the form, if the FORM is a POST

mailto:example@gmail.com?subject=About+your+extended+warranty

this was something that was more commonly used in the late 90s/early/2000s, an early internet feature, but still works to this day.

there are some niceties that have been added or maybe they were always possible - you can add a subject and message body, possibly cc etc.

i used it just last year to make an easy contact form for contacting local municipalities from a single website for my wife's NP

Which derivative?

If I had to guess, they are probably using XTDB, which is bitemporal, i.e. every entity has an associated "transaction time" and "validity time". You can use the validity time to deal with situations like "Company reported X assets and Y liabilities in their 2020 balance sheet, and in 2022 it was discovered there was some 2020 assets unaccounted for", and in addition to this, answer questions like "How much assets did Company believe it had in 2020 given the facts we know in 2020? How about given the facts we know in 2022?"

I am not sure how useful this is for versioning data though. It seems like an orthogonal problem to me.

I wish Discord supported OpenID Connect so I could use it as an authentication provider for Convex.

I had no idea Legend Keeper used CRDTs. That's awesome! What were some of the challenges?

To start with the good, building features in your app becomes super easy because your network layer is completely agnostic. Rather than making API endpoints for every new feature, you're implementing everything in the language of shared types like arrays and maps. The changes to those structures are simply merged with the server/peers and you don't worry about manually syncing stuff anymore. Everything you build now works offline by default, and collaboratively if you so choose.

Collaboration is where things get a little spicy. You're now dealing with multi-master replication. These challenges are exacerbated with multi-user use cases (though even a single-user experience is still multiplayer: one person using multiple tabs or devices is essentially multiple users in the eyes of most CRDT-based app architectures. You could also consider the server another peer.)

IMO, biggest challenge areas are data migrations, version management, data validation, and authorization. Sure you can migrate things on the server (if you're not building a P2P app), but you have to remember the server is now just a more authoritative peer; you can't guarantee your user will ever even talk to the server again.

If you don't have defensive data validation and stellar error handling, one peer can poison the others with bad data. It doesn't need to be a bad actor: you could simply add a bug to your code without realizing it, push it to prod, and now you've got viral data corruption. On the bright side, because your business logic is all in the client, unit and integration tests become super powerful. There's no need to mock a server and risk deviation from reality: the client is authoritative, therefore its tests are authoritative.

In my eyes, most of the challenges come from multiplayer. If you scope down your local-first app to a single-user experience + a server for backup purposes, I think things are pretty straightfoward. You'll still have to deal with version management and data migrations, but traditional desktop and mobile apps already have a rich history of best practices for this which can be emulated.

For data migrations / model versioning, have you seen Project Cambria [0], posted in 2020 [1]? (Also an inkandswitch.com project.)

[0]: https://www.inkandswitch.com/cambria.html

[1]: https://news.ycombinator.com/item?id=24699615