First of all, thank you for making Silverbullet. The idea and principles alone are amazing, but having it implemented is golden! I discovered it last week and have been exploring it, so I’m only familiar with v2. Great bet on the Lua thing btw!
Now, for the actual ideas:
I’ve seen around these parts that some people want multi-user and other people think of these as personal software. I fall in between the two categories: it’s familiar software, in the sense that I intend to use it with my (non-tech-savvy) family. Now, not everything is meant to be shared, but everything is connected. E.g. there’s a lot of homelab, our company and our house, all of which which are interconnected. The company and the house objects/pages are shared, but homelab is just for me, so a separate Silverbullet instance is far from ideal. If I knew who logged in, I could then setup adjusted dashboards, so It’s not about permissions it’s just about managing what should be focused/shown to whom. If a direct link to a homelab page is followed, any user can go there and edit it. This only requires multiple credentials and a user field in _CTX associated with the credentials. Sounds like a simple endeavour to me that would open a lot of possibilities, such as for small communities (think family, a group of friends, D&D sessions, whatever). There is already support for multiple concurrent clients, so as long as there’s not much overload (many people) syncing is not a problem.
In Silverbullet anything except an attribute is an Object. That’s awesome! But in reality one can’t query for all objects, only for objects of a certain tag. This makes it cumbersome to look for things generically, like all objects that have certain attributes. An index.all returning a query collection of all objects would go a long way and is probably not that hard to implement. Maybe this can be emulated with a bunch of index.tag(...) calls, but that’s lame for something as cool as Silverbullet
Taskstates are unbound! So if I need two different set of taskstates [Backlog, Doing, Done, Discarded] and [Considering, Finding, Ordering, Purchased, WaitForBetterPrice, Discarded], I will now have a single taskstate with 10 choices to navigate in all my space. My point is taskstate should be a special attribute instead, one that we can config.set/update its choices and used like [taskstate:name_of_my_state].
Attribute values are said to be YAML in the docs. This is quite false, as they can only be a string, a number or an array of string/number/array. They cannot be any form of struct because newlines are not supported and [attr:{sub1:val1,sub2:val2}] is considered a struct with two entries: sub1:val1 with value {} and sub2:val2 with value {}. Allow attributes to be real YAML even without newlines one can inline JSON in there. This might be a bug in your custom YAML implementation, but why have one in the first place!?
Lastly, I read before that you didn’t want to allow HTML in markdown because it’d be unsafe, but come on, we can already run everything with Lua, including changing DOM and running commands on the server. Not allowing HTML is not any more unsafe than what it already is, however it’s an annoyance to some of us (it’s not even a limitation!). You know what to do to be an ever cooler guy
Now for a question linked with the end of 4.: why do you have the custom query[[]] syntax? Why not just use a Lua engine that someone else (or team) developed and inject a function query(tag, {where:.., select:..., ...}? You’d reduce your burden by a lot! It might be too late now for a change like that to pay off, but I’m actually curious on why you decided to go on that route.
I consider all of these to bring quality of life and all (except maybe 4.) to be low-hanging fruits and should really be in core Silvebullet. I guess these are more of requests, but they are still ideas Thoughts?
You could just have one general user and then use a little bit of space lua with the clientStore to save the user. Selecting the user could be done by prompting the user if no user is yet saved with editor.filterBox, similar to the index page “hack”, just with a prompt instead of a navigation. Multi user setups aren’t really a goal of SB to my knowledge and the same applies to an extensive authentication system.
This would be very performance heavy currently. Although possible to add.
~
This is in fact quite true, as {sub1:val1,sub2:val2} is just not doing the thing in YAML you think it should do, SB is working correctly here. You probably want to use {sub1: val1,sub2: val2}
What would be your usecase? What speaks against using widgets?
Multiple credentials hardly seem “extensive authentication” to me But hmm.. I guess this could work for now!
Performance depends on your Space and devices and even smartphones have as much RAM as laptops these days. Like I said, one can already do this with a set of queries, it’s just cumbersome, so I’m not sure that’s a good reason to not do it, just put a warning on the docs.
Oh! I had a lot of tries to get more complex attributes and at first I got the syntax wrong because you can’t put multiple attributes under the same [] (which might have a very good reason, but [] means array to me for more than 20 years now, so it caught me off guard) and I might’ve discarded some tries during that time. Indeed JSON is a subset of YAML so the spacing shouldn’t matter, but only {"sub1":"val1","sub2":"val2"} would be JSON which does work as well. Thanks for pointing it out!
Nothing speaks against widgets, except I don’t always want the complexity of widgets. Sometimes I might want just a small extra decoration, why should I need to build a widget for each decoration or a big widget that handles all my decorations? I literally have to go out of my way to do It (opening another page, making some code, then getting back, reloading and trying it, probably multiple times).
Again, these weren’t about big new features, I think Silverbullet is in a very sweet spot, it’s just small QoL things that are easily achievable.
About the Lua engine, yeah, I see what happened :
I happen to (literally) have a PhD in compiler construction and programming language design
Just kidding! Actually, I just reread the docs and they also mention the async thing. I had also written a whole thing about what’s missing but it’s already there as well, except for the case when I delete an element of a table during the select part of query[[]] the key still appears in the resulting table (with nil value) when it should have disappeared, from what I read.
Kudos for a job well done, regardless, it’s an amazing feat for a single person!
Nothing speaks against widgets, except I don’t always want the complexity of widgets. Sometimes I might want just a small extra decoration, why should I need to build a widget for each decoration or a big widget that handles all my decorations? I literally have to go out of my way to do It (opening another page, making some code, then getting back, reloading and trying it, probably multiple times).
I’m just interested, what’s a “decoration”. What’s the use. Every time I’ve seen use of html in note taking systems, it was because it was missing a markdown feature. It was always more of a hack getting around some stuff.
Well, it’s simple stuff, like setting different colors or font sizes for parts that aren’t themeable. For instance, in my dashboard page I have a table with the names of the users in the header row, I want them bigger in that table but not the next table that appears. I’m just starting out with Silverbullet, since I already have an exception, I’m guessing I’ll have many more. Maybe I won’t, or maybe there’s a simpler way to achieve what I want, but in my mind I’d be having a css tucked in CONFIG with some classes that would be directly used in the regular pages.
Even though I at some point I was more determined to really double down on the single-user use case, lately my mind is wandering into the direction of what it would take to make SB good for teams/families/whatever. Authentication and authorization would be part of that, but also real-time collaboration, comments etc. When my ideas are more clear I’ll probably write them up. This is a big undertaking and I have to prioritize, though.
On large spaces this would be expensive as @MrMugame said, but it should be easy to add. Can you create a Github issue for this?
I think SB would benefit from various type of “schema style” additions to put more constraints on your object structure, but indeed also things like task states. This way we can do better (consistency) checking, code completion etc. Another project I’d like to tackle at some point.
As to the custom Lua implementation, @MrMugame already pointed to the original reasons, which still hold, but benefits I did not anticipate and are now paying dividends:
SB now has a “live” Lua environment running at all times, where everything is 100% under my control. Features like Space Lua code complete (while somewhat limited) were easy to implement because completion happens based on the actual current state of the live system. I can also do (best effort) jump to definition (Cmd-click), because I have all AST info in memory, which is another thing that would be near impossible with an off-the-shelf Lua implementation.
I can indeed do neat things like the query[[...]] syntax, which would have been a no-go otherwise. Coming up with a standard Lua API could have been possible, but definitely more limited and uglier. Since you’d want to use Lua-based conditions in where, you’d have to pass in callback functions etc. It’s not going to be pretty. You missed the pre-v1 days, but then we had a completely custom query syntax. A Lua API as you sketch out would be quite a tough sell and a clear downgrade from that.
Anyway, the custom Lua is a done deal at this point.
Hi! Sorry, it’s been some rough days.
1.
2. Yes, I’ll create a Github issue for it. In fact, I wanted to give it a shot myself, but I won’t be able to anytime soon I think maybe in about 2 months I can start doing it.
3. Oh, that would be awesome! I really feel like there should be a more enforced structure.
4.
5. Nice to know it’s ongoing!
Sure, it’s done and future benefits can be reaped, no point in taking it out now, it was just curiosity
even without newlines one can inline JSON in there. This might be a bug in your custom YAML implementation, but why have one in the first place!?
Thoughts?
But hmm.. 
I guess this could work for now! 
I think maybe in about 2 months I can start doing it.