I was having issues on Wed at the LA meetup evaluating code via nrepl. I haven't had a chance to figure out if it was my set up or biff.

oh yeah I remember that. that should be unrelated though (I also use vim + conjure funnily enough!) did you have trouble with nrepl the whole time, or did it work at first and then broke?

I only tried to do nrepl evals a couple of times. I don't remember it working for either. I'll try again tomorrow and report back.

In Calva after ./task dev this jack-in shortcut doesn't work:

{
  "key": "ctrl+alt+c ctrl+alt+j",
  "command": "calva.jackIn",
  "when": "calva:keybindingsEnabled && workspaceFolderCount > 0"
}

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.9.0"},cider/cider-nrepl {:mvn/version,"0.27.4"}}}' -M -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
nREPL server started on port 39357 on host localhost - 

; Execution error (IllegalArgumentException) at xtdb.api/eval13330$fn$G (api.clj:306).
; No implementation of method: :db of protocol: #'xtdb.api/DBProvider found for class: nil

So after ./task dev I use this command which prompts for the nrepl port, which gets pre-populated with 7888

{
  "key": "ctrl+alt+c ctrl+alt+c",
  "command": "calva.connect",
  "when": "calva:keybindingsEnabled && workspaceFolderCount > 0"
}

hm it's probably worth mentioning that in the docs

Is anyone working on a Nextcloud replacement yet? 😄

I've long thought an XT-based version of https://solidproject.org/ would be super interesting

Interestingly enough, an XT-based implementation of Solid is on the radar (albeit... no where but the radar). @U050CTFRT and I have chatted about Solid a few times and he attended Solid World in 2021. There are a couple chicken-egg problems here. One is that Solid itself is still evolving. It's kind of like solar panels... the longer we wait, the cheaper (in terms of implementation) it gets. The other chicken/egg is that xtdb 2.x plans to entirely separate storage from compute, which means a person could (in theory) save the Solid Pod data into xtdb itself, rather than CAS ids into xtdb with files on disk. That's not to say that shoving gigabyte-sized files directly into xtdb will ever be a good idea... but it's a conversation we can only have once that's even technically feasible. 🙂

As I typed all that, I was thinking to myself "this feels a lot like stop energy." 😉 If anyone were inclined to create an XT-backed implementation of Solid today, I certainly wouldn't discourage you. We just haven't found the time or energy yet. If anyone took the first steps, it's likely we'd get behind that effort if/when we ever found the time and energy.

Wow! I'm curious how deeply you (as in, anyone from JUXT) have looked at the Solid protocol? Back when I looked at it the implementation they had looked extremely half-baked, but I never studied the protocol enough to develop a strong opinion about it. Except perhaps about identity--the protocol says to use some kind of uri like or something as an ID--which IMO is silly when people are already familiar with the format, and if this thing is ever going to get any meaningful adoption it needs to be as frictionless as possible. Of course maybe you can just do a mapping. In general my impression of the project was "cool idea but could use a healthy dose of pragmatism" and thus my plan (were I to work on this) was to ignore their protocol and just build my own thing, but have it be open source and nail down a protocol after it gets some adoption. but idk, maybe the protocol they've designed/are designing would be worth sticking with.

I'm gonna have to do a writeup on this idea for the biff newsletter at some point

I think @U050CTFRT is more familiar than I am, at this point. imo, both identity and owned storage have a lot of merit and, although the protocol is definitely immature, some functional reference implementations would probably do a lot to flesh them out over the coming years. I have less fear around the implementation of the protocol than I have around the notion of letting service providers (potentially multiple of them) touch data they don't own. For example, if The Sample and Deobald's Sample Ripoff are both reading and writing to the same shared Solid Pod, and DSR corrupted the data, what would The Sample do? It's possible we're just back to a Windows 95 world where The Sample has to say "sorry, this file is corrupt now" but that seems less than ideal.

easy--just use XT, so history of all data is preserved 😉

in seriousness, yeah there are some open questions around that... another big one is how to get all these different services to agree on data formats. I kind of think of Solid as a platform/tool/thing that attempts to take all the non-essential friction away from building protocol-based applications. But the problem is that building stuff on protocols still comes with a huge amount of essential "friction" ha ha

TBH that's kind of why I haven't been as interested in it these days as I have before--I think the better approach might just be to stick with a relatively small number of widely used protocols. e.g. that's why I'm so interested in email/SMTP. IMO the biggest/lowest hanging fruit right now is for people to just build more stuff with the assumption baked in that the inbox is the user's central information hub. I am still interested in solid as more of a research thing though.

see also https://www.inkandswitch.com/cambria/

That's an article and a half. Wow.

Hey I ready your post and I only have a very minor tip: You mentioned you consider TinyMCE as the text editor. May I suggest you have a look at ProseMirror. IMO it is a much more programmer friendly library and great to build things on top of.

Thanks, I'll take a look at that. For getting started my main criteria is that I'd like to be able to drop something in and have a good default experience without needing to do much configuration; I figured TinyMCE looked pretty good for that and we can always switch to something else when needed. But if ProseMirror is good enough as a drop-in editor, should also be fine to start out with that.