I don't have any answers or strong opinions yet, but I feel like the legal/societal conversation should focus on "actions taken via XYZ" rather than "technology underlying XYZ". Similar to how GDPR, etc. cover actions like collection/storage of personal information, not specific technologies like cookies (despite what many believe!).

In particular, your examples bring these things to mind, which might be worth considering alongside:

- Any machine can host a server, with no third-party required except an ISP (if we're being pedantic, even that's not needed if use a mesh network, etc.). The main barrier to connectivity IME is NAT, but there are ways around that (e.g. make it a .onion service). I played with all of the above as a teenager, so it's not unrealistic.

- "Hosting a website" covers a lot of things, some of which are already illegal (e.g. CSAM). Just because we can spin up something without jumping through social media sign-up hoops, doesn't mean it can't/shouldn't be subject to legal questions.

- Hosting a website/blog/etc. does not come with the same questionable baggage as social media (algorithmic feeds, PII, tracking, identity verification, communication, etc.). We might opt in to such things, e.g. by accepting comments on posts, but I'd distinguish such two-way, "user generated" activity from merely "hosting a website". Technologically, such things require some dynamic system (usually a self-hosted or third-party backend), rather than "just" a static HTML server.

- There is no technological difference between a blog used like a personal diary, and a blog used to post reviews of Lego. Is there a societal difference? What about if they include photos?

- Posting things on a personal website/blog has an implicit understanding that it's being published and shared with the world (that feels like the whole point of a blog). Social media has muddied those waters, by claiming things like "privacy settings", which can give the impression that posts are not being published and shared with the world.

- When it comes to activities like receiving comments, two-way communication, unsolicited messages from anonymous strangers, etc. the more relevant "basic tech" feels like running a server for email, IRC, Jabber, etc. rather than a web site; since those place such "dangerous" aspects front-and-centre. Email is the most obvious, but I mention the others since getting external systems to trust a self-hosted email server is notoriously tricky!

> btw, Git also supports the HTTP protocol ...

In fact, Git supports any protocol! If you add a git remote like

    git remote add my-remote my-super-duper-protocol::some-sort-of-address-thingy

Then pushing/pulling `my-remote` will try to invoke a command called `git-remote-my-super-duper-protocol`, with `some-sort-of-address-thingy` in its arguments. You can implement that however you like.

I use remotes like "pkipfs::y5a9inx61aski4miz4sgmg55qgbazxhfwab3i6ee1ypa6rnumi8o", which invokes a custom git-remote-pkipfs command that pushes/pulls object data to IPFS and resolves/updates refs as subdomains of a specified pkarr address.

Whenever I try something else, I always seem to keep going back to E16. Back in the day, it worked well in Gnome 2.x; these days I tend to use it in XFCE, but it feels a bit less integrated.

Exactly the same thing happened when git showed up (alongside the same things for bzr, darcs, hg, etc. too!)

rare case of feature bloat for git. Still completely optional, thank god linus.

I suppose it depends what you mean by "horribly break things".

The only thing I've noticed is that `jj` will leave the git repo with either a detached HEAD, or with a funny `@` ref checked out.

I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

For someone who's less experienced, or only uses git for a set of branches with mostly linear history (like a sort of "fancy undo"), I could imagine getting a shock when trying to `git commit` and not seeing them on any of the branches!

> I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

I think most people that have git experience don't know what a DAG is and have never used reflog.

> It wants me to start with the new and describe command

jj doesn't "want" anything.

I always end a piece of work with `new`: it puts an empty, description-less commit as the checked-out HEAD, and is my way of saying "I'm finished with those changes (for now); any subsequent changes to this directory should go in this (currently empty) commit"

The last thing I do to a commit, once all of its contents have settled into something reasonable, is describe it.

In fact, I mostly use `commit` (pressing `C` in majutsu), which combines those two things: it gives the current commit a description, and creates a new empty commit on top.

> I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion.

I do that all the time. With git, everything starts "unstaged", so I'd use magit to selectively stage some parts and turn those into a sequence of commits, one on top of another.

With jj I'd do it "backwards": everything starts off committed (with no commit message), so I'd open the diff (`D` in majutsu), selecting some parts and "split" (`S` in majutsu) to put those into a new commit underneath the remaining changes. Once the different changes are split into separate commits, I'd give each a relevant commit message.

Tooling can support both (e.g. don't assume all hashes have the length of a SHA1, etc.); but they can't be used together in one repo.

Haskell has a package to make testing this sort of thing easier https://hackage.haskell.org/package/inspection-testing