Skip to content

Yet Another Standardfile (standardnotes server) Implementation written in Golang

License

Notifications You must be signed in to change notification settings

mdouchement/standardfile

Repository files navigation

Yet Another Standardfile Implementation in Go

This project is maintained for the basic features as encrypted notes because on its own it already takes hours to figure out what is the issue when a breaking change or bug happens (e.g. #87).

People's pull requests that implement or fix extra features (revision, file storage, etc.) will be gladly reviewed and merged.

  • For any bug linked to the code or its faulty behavior, please take a look to the existing Issues and feel free to open a new one if nothing match your issue
  • For any question about this project, the configuration, integrations, related projects and so one, please take a look to the existing Discussions and feel free to open a new one

GoDoc Go Report Card License

This is a 100% Golang implementation of the Standard Notes protocol. It aims to be portable and lightweight.

Running your own server

You can run your own Standard File server, and use it with any SF compatible client (like Standard Notes). This allows you to have 100% control of your data. This server implementation is built with Go and can be deployed in seconds.

https://hub.docker.com/r/mdouchement/standardfile

Client library

Go to pgk/libsf for more details. https://godoc.org/github.com/mdouchement/standardfile/pkg/libsf

It is an alternative to https://github.com/jonhadfield/gosn

SF client

go run cmd/sfc/main.go -h

Terminal UI client: sfc note

Requirements

  • Golang 1.16.x (Go Modules)

Technologies / Frameworks

Differences with reference implementation

Drop legacy support for clients which hardcoded the "api" path to the base url (iOS)

Permalink

Drop the POST request done on Extensions (backups too)

Permalink

This feature is pretty undocumented and I feel uncomfortable about the outgoing traffic from my server on unknown URLs.

Drop V1 support

All stuff used in v1 and not in v2 nor v3

JWT revocation strategy after password update

Reference implementation use a pw_hash claim to check if the user has changed their pw and thus forbid them from access if they have an old jwt.


Here we will revoke JWT based on its iat claim and User.PasswordUpdatedAt field. Looks more safer than publicly expose any sort of password stuff. See internal/server/middlewares/current_user.go

Session use PASETO tokens instead of random tokens

Here we will be using PASETO to strengthen authentication to ensure that the tokens are issued by the server.

Not implemented (yet)

  • 2FA (aka verify_mfa)
  • Postgres if a more stronger database is needed
  • A console for admin usage

License

MIT

Contributing

All PRs are welcome.

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request