### Author:  [@zef](https://community.silverbullet.md/u/zef)
#### Post date: [June 27, 2024, 8:09am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/5 "2024-06-27T08:09:42Z")
I’ll have a closer look at that. Another potential thing to consider is merge the PLUGS page into SETTINGS. By making the list of plugs to install simply a setting. Not sure about this one yet.
---
### Author:  [@Maarrk](https://community.silverbullet.md/u/Maarrk)
#### Post date: [June 27, 2024, 8:34am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/6 "2024-06-27T08:34:31Z")
I like the current separation between PLUGS and SETTINGS. Keeps the plug list simple, and I’m able to see what I have there at a glance. Downloading and installing a plug can fail more ways, so I think it’s good that we can’t have “you made a typo in the yaml key” mixed together with them.
But I just had an idea that it would allow to “auto-scope” settings really nicely, and avoid name clashes even more:
```yaml
plugs:
- uri: github:silverbulletmd/silverbullet-git/git.plug.js
autoCommitMinutes: 30
autoSync: true
```
>
>
> Right now various plugs implicitly read values from \`SETTINGS\` possibly document…ing them, possibly not. It would be nicer if plugs can explicitly define their settings as well as their schema (at least their type). Same for \`SECRETS\` I suppose.
>
> Not only is this better for documentation, it would also enable building a automatically generated proper settings UI listing all settings, changing them etc. Something more intuitive than YAML in a page.
>
> Not sure how this should be specified yet, one way would be to extend the \`.plug.yaml\` format at the PlugOS level, something along the lines of:
>
> \`\`\`yaml
> name: core
> settings:
> initPage:
> type: string
> default: index
> description: Specifies the first page to load when loading your space
> weeklyNoteTemplate:
> type: string
> default: template/Weekly Note
> functions:
> # …
> \`\`\`
---
### Author:  [@MrMugame](https://community.silverbullet.md/u/MrMugame)
#### Post date: [June 30, 2024, 12:59am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/7 "2024-06-30T00:59:55Z")
I would like the excalidraw situation to be sorted. The last idea was to replace the code inside a fenced code block with the exalidraw content. After trying to implement this (which is probably possible but super annoying; I couldn’t get it to properly work, long story blabla…). This would also have some problems:
- Lines are wrapped; If there is like 3kbs of JSON in there it would be wrapped into oblivion
- Performance issues with codemirror
- File formats other than excalidraw, which aren’t text based would probably look weird `53696c76657262756c6c6574206973206120677265617420746f6f6c`
- The saving would need to be “live”, because if a fenced code block gets rendered as text again, the iframe is yeeted and has no time to change the text anymore (save). Live saving isn’t really feasible all the time.
Anyways, my idea would be to add the ability to open attachments file, which would be implemented via plugs. So there is some kind of attachment picker and if there is a registered file viewer (from a plug) for the filetype the file is viewed in it. This viewer would be some iframe, which also has some api to talk to the system. This could also e.g. allow us to let the plug index attachments in some way. A good example would be the csv indexing: This could be a plug with a csv viewer, which just renders the table as some html and also has an indexing function (separate from the iframe, running in the webworker) which could index it. This could exists for archive filetrees, image metadata, rtf/doc files, sqlite db file, etc. (Probably insane amount of ideas here). Another viewer plug could be e.g. pdfjs, with some kind of annotation system. Or an stl viewer for our fellow 3d printer owners. This definitely needs some thinking (How is syncing handled, etc.), but I think this could be something insanely powerful.
(At some point in version silverbullet 69, the standard editing mode could just be a builtin markdown viewer plug)
EDIT: A few more thoughts: Indexing could actually be completely separate from viewing (which should really say viewer/editor). So one could have different plugs for each.
Mobile support could be ugly here, as we have to trust the plug devs.
This is also kinda possible already using panels, so a lot of the infrastructure is already in place.
I could see the argument that this is something for a 2.0 release, rather than a 1.0
---
### Author:  [@MrMugame](https://community.silverbullet.md/u/MrMugame)
#### Post date: [July 2, 2024, 1:47am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/8 "2024-07-02T01:47:50Z")
If that like is a “go”(?), I would start drafting out that idea more concretely in a PR.
---
### Author:  [@zef](https://community.silverbullet.md/u/zef)
#### Post date: [July 2, 2024, 6:08am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/9 "2024-07-02T06:08:32Z")
I’d be interested in more detail. But it does seem like a bigger topic, perhaps not essential for 1.0.
---
### Author:  [@justyns](https://community.silverbullet.md/u/justyns)
#### Post date: [July 2, 2024, 9:31pm UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/10 "2024-07-02T21:31:28Z")
Something I think would be a good goal for 1.0 is support for multiple panes/splits or maybe even tabs.
I find myself wanting to open two notes side-by-side pretty often. I don’t usually have much of a need for more than just two notes at a time, but I’m sure others probably do.
Related:
- [Plug idea: Side page · Issue #245 · silverbulletmd/silverbullet · GitHub](https://github.com/silverbulletmd/silverbullet/issues/245) (sorta)
- [Split pane or sliding pane](https://community.silverbullet.md/t/split-pane-or-sliding-pane/481)
- [Navigation on left side?](https://community.silverbullet.md/t/navigation-on-left-side/153) (sorta)
Other ideas:
1. Read-only mode toggle per page.
2. Ability to “zoom” into a code block or section and edit that section only, hiding the rest of the note. This would be really useful for spacescript/spacestyle instead of having to edit inside of a code fence.
3. Note history - The git plug solves most of this already, so maybe it’s a better feature request there - but some sort of UI for browsing and restoring from previous note versions.
---
### Author:  [@MrMugame](https://community.silverbullet.md/u/MrMugame)
#### Post date: [July 2, 2024, 10:18pm UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/11 "2024-07-02T22:18:21Z")
This would be not very easy right now (like Zef already mentioned in the referenced threads) as the editor code is very tightly integrated into the rest of SilverBullet, so running two or more at the same time would be kind of difficult. We would need to separate the editor out, which is kind of what I proposed above or [here](https://github.com/silverbulletmd/silverbullet/issues/913).
---
### Author:  [@pihentagy](https://community.silverbullet.md/u/pihentagy)
#### Post date: [July 3, 2024, 11:57am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/12 "2024-07-03T11:57:50Z")
> [@justyns](#):
>
> Ability to “zoom” into a code block or section and edit that section only, hiding the rest of the note. This would be really useful for spacescript/spacestyle instead of having to edit inside of a code fence.
That would make SilverBullet an excellent outline editor, but I suspect that this kind of feature would be difficult to implement. ☹
---
### Author:  [@zef](https://community.silverbullet.md/u/zef)
#### Post date: [July 3, 2024, 4:18pm UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/13 "2024-07-03T16:18:22Z")
On the topic of a side panel or split view: I see this as a huge potential development tangent.
“Just give us a vertical split for a second page!”
“But I’d like the split to be horizontal!”
“Tabs please!”
“Tab management please”
“Vertical tabs!”
“Tab groups!”
“I have a 30” screen and want three splits"
“I’d like to resize the panels”
“I’d like panels to be swappable with a keyboard shortcut!”
‘I’d like to save different configurations of panels and have them automatically restored, except of mobile screens smaller than 8" on the third day of the week’
My way to get out of this is to delegate this responsibility to the browser. Browser support multiple windows, multiple tabs, and some (like [Vivalidi](https://vivaldi.com) which I’m using right now) even split views.
---
### Author:  [@zef](https://community.silverbullet.md/u/zef)
#### Post date: [July 3, 2024, 4:21pm UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/14 "2024-07-03T16:21:09Z")
> [@justyns](#):
>
> Note history - The git plug solves most of this already, so maybe it’s a better feature request there - but some sort of UI for browsing and restoring from previous note versions.
I have notes (in my private SilverBullet) on implementing a versioning system. I can see that this is a nice to have (and is implementable as a plug), but is also a potentially huge feature that will likely always be worse than using git. When using git in any meaningful way you’d essentially need to SSH into your server again, but ok. For me in practice I use git with auto commit enabled every 15 minutes that pushes to a private github repo. This gives me piece of mind backup and version wise.
---
### Author:  [@zef](https://community.silverbullet.md/u/zef)
#### Post date: [July 3, 2024, 4:33pm UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/15 "2024-07-03T16:33:25Z")
I don’t want to be the nay-sayer all the time, but one of the challenges is that I’d really like SilverBullet to remain sustainable as a hobby project with one primary developer by design. The goal is not to remain the main developer myself, but to keep the scope small enough that it could remain a one-person operation, if need be. I think this is healthy.
If this project starts to grow to require a full team, I have to start to look at funding and who knows where things may go when this goes commercial. It may be ok, but we’ve seen plenty of cases where that’s the beginning of the end. It’s not easy to get this right. Look at almost any large scale open source project out there that tried to turn into a business.
Therefore I’m trying to keep the focus tight and give the project a somewhat finite scope. Nothing is ever done, but I do hope to get to a state where the core is stable and rock solid. The way to grow it beyond that would then be plugs, or just to create workflows that also involve other applications outside of SB (which is an option because it’s just files on disk).
Throughout my career I’ve been working on massive feature creeped systems and would like to avoid it to the extent I can with SB.
That’s why I often ask: what features can we delete? People that have been here longer will remember we used to have mobile and desktop apps — removed. Real-time collaboration and multiple accounts — removed. A lot of hardcoded slash commands and templates — removed (in favor of the new templating system). Every time I’m eying a major new thing to add, I’m also looking at something else to get rid of.
---
### Author:  [@Pietzaahh](https://community.silverbullet.md/u/Pietzaahh)
#### Post date: [July 4, 2024, 5:24am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/16 "2024-07-04T05:24:52Z")
For a 1.0 release, feature-wise, I’d say you already have everything you need. You might even want to consider removing features which are currently unstable to be honest. I don’t have anything to point out specifically that’s unstable, but 1.0 should be a little “scrappy” imho. Make it stable, but don’t make it everything.
---
### Author:  [@justyns](https://community.silverbullet.md/u/justyns)
#### Post date: [July 4, 2024, 6:55am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/17 "2024-07-04T06:55:02Z")
Just to clarify, my thinking was just to improve the current git functionality by adding some UI/UX around it. Like a command that pops up a filter box with previous revisions of a file and lets you swap between them.
Adding a full-blown versioning system doesn’t seem worth it to me if we already have git that can do it for mostly free.
I can create a GH issue for the git plug though, I don’t think anything would need to be done in the SB core to support it.
---
### Author:  [@justyns](https://community.silverbullet.md/u/justyns)
#### Post date: [July 4, 2024, 7:30am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/18 "2024-07-04T07:30:56Z")
Hopefully you don’t feel like a nay-sayer, having a clear focus on what you want to accomplish is a huge benefit to keeping a project healthy.
I really like @MrMugame’s proposal [for custom editors](https://github.com/silverbulletmd/silverbullet/issues/913). Maybe I’ll change my recommendation for 1.0 (or maybe beyond) to this:
What can be extracted from SB core into plugs that could later be replaced by different community plugs? E.g. what are plugs not currently able to do or replace? The more plugs can do, the less sb core would need to be responsible for in the long run.
Also how can we improve the experience around plugs in general? There’s the [list of plugs](https://silverbullet.md/Plugs), but would a more automated registry be helpful? Or a ‘click to install’ type of button/command?
---
### Author:  [@zef](https://community.silverbullet.md/u/zef)
#### Post date: [July 4, 2024, 8:38am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/19 "2024-07-04T08:38:20Z")
An even more radical approach: ditch plugs, and go all-in on space script. Rewrite all plug code as space script libraries. 😄 How do you like them apples?
It’s been a thought, but I don’t think we should do it. SB is great for note taking, but we’d effectively have to turn it into a fully fledged IDE if you are you are going to write significant amounts of code in it and that… would be quite the tangent. One I’m prone to go into, since I worked on multiple in-browser editors/IDEs in the past 😆
Anyway, just to make the point I’m willing to burn quite significant parts of the product if there’s better, newer ways. I never saw an idea like space script coming a year or two ago when I started this project, and I still have concerns about security and stability but… it seems like people are really liking it, and this leads to some confusion. What should be built into the core, what should be a plug and what should be a space script?
---
### Author:  [@meain](https://community.silverbullet.md/u/meain)
#### Post date: [July 13, 2024, 6:19am UTC](https://community.silverbullet.md/t/towards-silverbullet-1-0/539/20 "2024-07-13T06:19:57Z")
Just a thought on this as an Emacs user. The best part about customizing Emacs is that if you want to build a quick hack, you just write and evaluate some elisp somewhere, but if that thing grows, you just put the same exact thing into a separate file and eventually into a separate repo and publish as a package.
I feel like space-script could do something similar. For small hacks that folks might want to do, space script is awesome, but if/when it gets larger and needs to be maintained more like code, you pull it out to a PLUG which can be “installed” and updated automatically by multiple people.
One of those examples for me personally is [Migrating from Obsidian-Tasks - #14 by paletochen - Showcase - SilverBullet Community](https://community.silverbullet.md/t/migrating-from-obsidian-tasks/292/14) which I would totally use as a PLUG, but just copy pasting the snippet feels a bit odd.
[Next page](https://community.silverbullet.md/t/towards-silverbullet-1-0/539.md?page=2)