Your plans for version 2.0

Community
#1

CodiMD 1.6.0 announced that it’s the last version of 1.x.

We want to go forward and develop a version which introduces some breaking changes. Version 2.0.

I already provided some thoughts to it in the community chat, but would love to have a bit more discussion about it over here.

Plans:

  • Remove the not so great embeddings and replace them with with URL-based replacements (i.e. instead of writing {youtube <some id>} just paste the link in a single line)
  • Rework configs as it’s done in a currently open PR (probably replace config.json with a config.yaml and getting rid of the split between dev, test and prod environments within the same file)
  • possibly rename if we come up with a good name on time
  • Add basic user profiles
  • Relocate notes to an own sub directory (from https://demo.codimd.org/<some uuid> to https://demo.codimd.org/n/<some uuid> or similar) but with backwards compatibility
  • Working towards having an actual, standardized API
  • Reworking internals towards TypeScript

To be clear, I can’t do all of this on my own, and it’s not a made decision, I want your input on it, but that’s at least my vision for 2020. I would love when there would be people who also want to work on the front-end and make some improvements towards UI/UX there as well. I really invite you to share your ideas with me in this perspective and I would like to setup some tasks on Github soon, so people who want to help, can easily find a spot to get their hands dirty :slight_smile:

Work has started: https://github.com/codimd/server/pull/280

6 Likes
Renaming yet another time…
#2

It looks like a good plan! Out of curiosity, what is the reasoning for “Relocate notes to an own sub directory”, I have no objection to it, just wondering if there an open issue with more context that I can read to catch up.

1 Like
#3

Main reason for the relocation is the conflict in free URL mode which causes things like documents existing at https://codimd.example.com/robot.txt which is rather bad. For now we fight this by having forbidden NoteIDs, but I think the better solution would be to move things into a sub-directory and define an API for it.

1 Like
#4

Although this thread is more than a month old and I didn’t contribute for about a year now I followed the story quite a bit and collected some thoughts.

First of all, though off-topic, I want to express my support for this project and honour @sheogorath’s fair attitude and open mind throughout the difficulties with HackMD.

Secondly, though I never compiled and thus seen @amenthes’s profile page I’m excited.

Feedback

  • TypeScript :+1: (thx @davidmehren)
  • API :+1:
  • Note sub directory: Although this makes things clearer and easier I’m not a huge fan of this.
    • I like short URLs
    • Maybe we should think about namespaces for users or even groups in this context
    • Maybe we could relocate UUIDs but leave the opportunity for even newly created freely chosen IDs (if they are activated)

Idea: Hooks

I think we are missing a hook system for the API/CLI, so we could hook Listeners on events to export the notes, do some stuff like a git commit or add support for WebDAV.

Taking inspiration from Android sensors, which accept sampling rates, we could define some approximately frequencies the listener could request, like:

  • live: every change (may cause heavy load)
  • minutely: every minute, if changed
  • revision: every saved revision
  • offline: when no user views the document (may never occur)

I guess this is a quite important feature for interoperability.

Further Ideas

  • Groups
  • Some way to structure and organise notes
  • File system-compatibility (WebDAV?) although no inotify
  • Full text search
  • Extensive tagging
  • Cross-document references
  • Frequently visited notes (quite related to the history data model)
  • Import websites (including bookmark link)
  • Better spell and grammar checking, maybe even something like Hemingway App or Grammarly
  • Lint the Markdown
  • Render preview with custom themes (useful for corporate design)
  • Custom designs
  • Make all features clickable (WYSIWYG-alike)
  • GUI for YAML metadata
  • Paste links in corresponding syntax
  • Plugin system, maybe based on APIs/FaaS
  • Exports with Pandoc!
  • Handle disconnects or even implement an offline mode
  • Add IPFS.io as an upload storage

Well, many ideas might be boo big or even unnecessary but I want to share them anyway, hoping that I get some feedback. I can elaborate on those in separate threads or issues, if somebody is interested. Do we have an ability to run some permanent ranking of the most wanted features by the way?

Tools like MS Word enable users without expertise to write whole books, while such as Evernote empower them to organise themselves. Although my personal preference is stability over functionality the extensive functionality was a strength of HackMD.
For me such tendencies are a good inspiration, how about you?

2 Likes
#5

Icon

Maybe it would be a good idea to change the CodiMD Icon?

Together with a renaming this could yield a whole rebranding of the software. Currently the CodiMD Logo is the same as HackMD and HackMDs CodiMD, which does not really help to differntiate the projects. Maybe we could use a File Icon with the markdown mark instead?
Like so:

file-markdown
(I’ve made a svg version, but this can’t be uploaded here)

It’s simple and not to much of a difference. Also it’s custom build from some font-awesome icons (which we would need to credit, but I think that’s done already?) so other projects can’t simply use the same icon via font awesome.

We could also ask for icon drafts like gitea did a few years ago. Maybe someone more creative than me has a better idea…

3 Likes
#6

What is necessary for exporting with Pandoc? Is the CodiMD api able to be used with something like this restful api version or even the hosted demo instance at pandoc.org/try

I’m interested in using Codi to draft out mediawiki pages.

1 Like
#7

The API looks quite… abandoned, although it would be intriguing. My approach would probably be to include Pandoc via Docker and build the stuff that is necessary for CodiMD to convert and send the document as a HTTP response.

2 Likes
#8

My 2 cents:

Make it possible to easily disable functionality. In my CodiMD instance, I feel like there is a lot of functionality that is unused, and also unneeded. A lot of these things feel in some way like “plugins”. If it’s possible to slowly move to an architecture where it’s possible to disable or add new custom plugins, that would be super-cool. This obviously is also related to the “hooks”-idea proposed earlier.

2 Likes
#9

Seems like @HerHde already mentioned most of my points, but I wanted to reiterate.

  • Allow assigning users to groups
  • Ability to assign notes to a group, and user private note if not explicitly assigned
  • A page (My Notes) to list notes that a user has access to (not just history)
  • Allow users to view notes assigned to groups they are a member of.
  • (possibly) allow separation of notes by group
3 Likes
#10

Question:

  1. Who, when, and where are the decided features for version 2.0 going to be set in stone?

  2. When is the expected/anticipated/hopeful release date for version 2.0?

I am not a JavaScript guy, but if there is a decided list of features ready for development I will take a look and see if there is anything I can try out.

1 Like
#11

When it comes to the who, generally speaking it’s the community and their interest in features. Technically speaking it’ll probably be me who presses the merge button but will definitely happen in exchange with people in the community.

When is one of those questions in software that is close to impossible to answer. We expect 2.0 around August, earliest. The general perspective is: Whenever things are ready and/or required.

And the where: On GitHub and the community chat. Currently the change set for 2.0 is already rather big. Therefore the goal is getting towards reasonable stability and going towards release. Especially in the back end there is still a lot to do. But we are getting there.

#12

Here’s some Ideas I came up with.

  • Markdownlint (@HerHde)
  • an optional (configurable) index of all visible notes for logged-in users (see #455)
  • prefixes and / allowed in pad identifiers to make folder structures in the ^ index
  • An offline-first smartphone app
  • +1 on the “please keep short URLs” – I also quite heavily use “pad.mydomain/super”
  • Group/User ACL – maybe just MVP it Unix-Style
    • the current “limited/freely/private/protected” could be enhanced to o+rw g+r a-
  • TypeScript for easier modularisation… Or maybe just migrate to ES6 and skip all the tsc headaches?
3 Likes
#13

As a new comer, these are the first noticed features that Codimd/Hedgedoc is missing.

New suggestions:

  1. Support for auto language directions (include dir=“auto” in the HTML markup of each element like paragraph, heading, list, to-do list, …).
    This is so much important for RTL languages like Arabic, Hebrew and others.

  2. Import all existing .md notes at once from local storage, instead of: one by one.
    Not sure if this already exist (because it’s crucial for new comers), but have no idea how to do it.

Already suggested:

  1. Folder/directory structure for notes organisation (like Notebooks).

  2. Contextual search (Search for notes content also).

3 Likes
#14

Here’s another idea:

  • Signup restrictions for the OAuth providers
    • this is already supported for G-Suite users
    • however, f.ex. with GitHub, I want to limit users to those belonging to an org or a team
  • Signup restrictions for email
    • I want to limit that only users of specific domains can sign up
    • this means that the emails will have to be validated with a signup-token
4 Likes