As a content creator, I want viewers of my work to understand how they may or may not use my work, so that I can share links to the work publicly without fear of it being plagiarized.

• Select license on create
• Modify license
• Show license in view mode
• Show license in edit mode

Hi @nsreed,
Seem like a cool project evolving here.
You might want to check out https://gitlab.com/MeldCE/first-draft --a similar project built with paper.js and node.
Might help inform development.

It would be nice to be able to load the website while offline and use the local data that my browser already knows about. Hypothetically once peers are available on the local network, we ought to be able to disconnect from the internet and still create and pull updates without the /gun peer being available.

It looks like this might be partly done via service workers, and since gun already uses the indexedDB for offline stuff we're like 80% of the way there.

You should be able to clone selected items. Cloning them should create a copy in-place, and select the copy.

As a user, I want an option to apply smoothing to pen strokes, so low temporal/spatial resolution strokes can be captured as they were drawn (more or less).

If you draw too fast, the most recent portions of your line will jitter and occasionally replace your line with a straight line between the last "stable" line end and your cursor position. Likely due to faulty locking logic.

• fontawesome & mat-icon glyphs fail to load
• can't create new vectors
• existing vectors won't load content

Needs more testing.

Add raster image support, for things such as background image tracing. Should be able to "upload" an image from your device (paste, drag&drop aren't mobile friendly).

We want to think about development processes related to contributions / pull requests etc. So

• Make it clear to others on how to submit pull requests.
• A tentative vetting process for contributions (in particular the package.json changes)
• Some kind of Contribution guidelines.
• Look into the necessity of Contributor License Agreements.

• Validation
  • User exists
  • Passwords don't match
• Disable submit button when form submitted
• Progress spinner
• Connection/GUN error

I want to be able to edit properties for selected items, such as:

• Fill color
• Stroke color
• Stroke width

You should be able to copy/paste selected items.

• Copy
• Paste
• Pasted items should be selected to facilitate moving them (since they'll be in the same location as their originals)

It would be nice if this could use the system clipboard.

Need a color swatch. It should store colors in a way that can be easily recalled for stroke/fill color selectors.

• Add
• Delete

While testing, we ran into a bug and then proceeded to delete accounts locally and in the process lost access to a drawing.

Occurred to me it would be useful to have a save/download/export and load/upload/import feature to allow for backups in case of replication failure and peer loss.

Long term this may be covered by gun implementing IPFS connectivity, but for the time being just having something that can be deposited into a .json would be enough.

I suspect it wouldn't be much different from the bug report feature in how it's implemented in the UI.

Aside from CPU fan noise, there is no way to tell if ouronote is still loading vector data. While I don't have a good answer for how to accomplish this in p2p world (the reality is that you don't know what you don't know about what data there is in the graph on other machines), there needs to be some kind of loading bar for known data, even if it's a non-deterministic one.

One of the cool things about Ouronote is that the zoomable whiteboard inherently makes viewing the art easier for those who are visually impaired. There is no real concept of size baked in, so how big something is on the screen is largely up to the user.

Given that, I've had some luck using this tool to share content with others who struggle to see small things or have strong prescriptions. Been thinkin about ways to enhance this a bit when I am not directly in the presence of people or sharing it while screenshare'ing.

It may be an easy win to give users the ability to enter in "ALT text" for an image in a similar way as how the copywrite system is embedded.

We can then take this content and have it be visible to screen readers, thus making it more accessible for when someone clicks the viewable link.

As the user zooms in, scaling the effective stroke width based on the viewport would make it easier to draw small and large drawings without needing to manually resize the stroke weight.

Why AGPLv3?

ouronote is for everyone.

The GNU Affero General Public License is a software license provided by the Free Software Foundation. It is a version of the General Public License that includes clauses about providing the source code to users of a product, even if the software is accessed over a network.

Generally speaking this does not cause too many complications if your intention is to release code that is accessible to others, which ouronote intends to do.

While the specific details of the license are contained within the AGPLv3's text (and I am not a lawyer), the basic requirements appear quite simple:

• This license does not require you to commit code changes back to the original source.
• It does require a facility to freely share your application's source code with any modifications you've done to it,
• and most importantly, to ensure this is made accessible for users of the software even if used over a network.
• Users also must be allowed to copy & use that code under the same license agreement you've been provided with for this project, or another compatible license as the case may be.

Typically this means little more than including a user-accessible link to your copy of the server's code repository (including changes you've made) and ensuring it is accessible from the internet.

AGPLv3 facilitates peer-to-peer compatibility:

ouronote is for everyone.

Being peer-to-peer, ouronote may run on a diversity of unknown forks all interacting together.

By using a license that demands server forks release their code to the user, it facilitates sharing of features within the ouronote ecosystem as a whole. The intention is for future developers to more freely coordinate around porting network compatibility changes (or upgrade as a collective) without worrying about license conflicts.

This does not mean that network schisms won't occur or that incompatible features won't arise, but it is at least a step toward ensuring that compatibility can be maintained where possible. In fact, we encourage communities to customize their software to their needs!

AGPLv3 helps protect from hostile take-over:

ouronote is for everyone.

Under AGPLv3, the service's code must be shared with everyone who uses it, so as an ouronote user you will always have the right to access the code.

One of the long-term failure states of federated/decentralized platforms is having some corporate behemoth takes over and effectively centralize it. We don't want your access to ouronote (and your artwork) to be artificially restricted in that manner.

By licensing AGPLv3, we effectively scare away centralized providers from co-opting network effects and then gating things behind a closed ecosystem.

AGPLv3 helps to maintain software freedoms:

ouronote is for everyone.

By requiring source code to be released to those who use the software, AGPLv3 ensures the core 'software freedoms' sought by copy-left licensing. This means being able to easily verify, modify, and share the code running on your computer.

And as such, AGPLv3 ensures people can confirm that the JavaScript running in the browser is what it says it is. It also lets people run their own copy of the software if that is a better fit for their needs. We feel these are important toward ensuring that ouronote is as widely available as possible.

Exceptions.

AGPLv3 is an 'infectious license', and this has raised concerns in the past on other creative platforms. We want to ensure you're comfortable using ouronote, so we've listed off some notable exceptions.

Created content is yours and yours alone:

To be very blunt: we are not trying to steal your work. We simply want to ensure the software used to create & view your work stays freely accessible to you (and everyone else) in the future.

Given this is a creative tool intended to allow users to produce their own content, all the content created by the user (and any templates provided by the software used to create that content) will necessarily need to be licensed separately. The GPL documentation highlights how to facilitate this. And we'll be taking steps we to ensure this is possible.

We will choose a CC0 license (or similar) for anything ouronote provides that your work may be considered a derivative of.

We are licensing the software, not your creations. If something we've done with our licensing has gone against this idea, please consider it a mistake.

Embedded applications?

ouronote is for everyone.

Fundamentally, we see ouronote as a tool for users to share their art with others. We believe you should always have access to the direct tools used to create and share content made with it. With that in mind, facilitating the sharing of ouronote creations out over social networks, forums, message boards, imageboards (and various other social web-based applications), makes sense.

If we get to the point in our life-cycle where this is a demand, a possible future exception is using this application in an web embeddable form. To be able to use ouronote this way, will enable access to share your content as openly as possible.

While we want any changes to ouronote itself to remain freely accessible to the users, we recognize that software licensed under AGPLv3 can be challenging to adopt by larger organizations. By allowing for ouronote itself to run as an embeddable widget, it can perhaps be made available to users under the AGPLv3 clause without forcing the larger project to relicense their code.

So one important exception here is that we may release an adapter that has been more permissively licensed. This is so other projects who wish to embed ouronote do not pollute their project as a whole, while still forcing the larger project to give ouronote users the intended software freedoms. This is in line with past conventions for integrating AGPL software with 3rd parties.

If we're unable to resolve the conflicts this may present, we will choose to maintain the rights that AGPLv3 provides.

Concerns over internal libraries.

At the current time, there are libraries contained within this repository that are intended to be released and licensed more permissively. An example being the angular=>gun adapter, and paper.js=>gun adapter.

These boundaries are not clearly marked yet, but will be in the future. They will be separated from the ouronote app itself and made freely available to the larger software developer ecosystem under a different license.

Why you no use license [insert favorite license here]???

To quote the Free Software Foundation: "We recommend that developers consider using the GNU AGPL for any software which will commonly be run over a network."

If you want more information on this license, I recommend reviewing the FSF's "why AGPL" where they discuss the motivations. Also possibly watching John Sullivan talking about how AGPL is being used in the wild.

We realize this choice makes people bristle because we are effectively forcing your hand if you choose to work on ouronote. However, access to these freedoms is something that we feel strongly about, and view it as necessary for enabling the kind of software we want to use ourselves, so it likely won't change in the future.

The only exceptions is possibly deciding to dual-license along with those with similar server-side code publishing requirements, provided they are in line with the ethos described above.

So

• We need to verify that we can publish under AGPLv3 or another compatible opensource license.

This app wouldn't exist without the FOSS community being what it is. We want to ensure we're not being rude other developers who's work we've depended upon. So

• We must ensure that we've attributed things appropriately somewhere in the app.

I clicked on bug report and it brought me here when I clicked on github issues. I have no idea what this stuff is or how you want it to be presented. I'm assuming you want me to do something to submit an issue, but as I've never interacted with your thing, I don't know what you expect.

I also saw some junk under "preview" and it seems to be copied to my clipboard when I click copy. But I also see it lets me download it as a .json?

Should I attach it as a file? If you include the ``` junk in the copy/paste, it would make it easier to include that way, but it ends up being a mess?

I can't copy it in here. It says

"There was an error creating your Issue: body is too long (maximum is 65536 characters)."

and if I try to add the .json file it says

"We don’t support that file type. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, CSV, DOCX, FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX, TXT, XLS, XLSX or ZIP."

I would love some options to not include stuff like what peers I'm connected to. and maybe replace my public token with '[token removed]' placeholder or something like that.

• Single Item
  • Bring to Front
  • Send to Back
• Multiple Items
  • Bring to Front
  • Send to Back

As a user, I want a way to easily download a vector as a .png/.svg file, so that I can use/share it outside of ouronote.

• Background color
• Size
• Position
• Preview

Update the preview by exporting JSON to a WebWorker paper instance. Export that SVG/Raster/canvas data to host, display in img tag, CSS to fit to preview pane.

It would be nice to have a tool that selects a color from the canvas and applies it to the current style

• Add "download as PNG" button to editor
• Remove "download" link from vector cards
• Remove "import" button from vector list

Pen input lag is too high to be useful for handwriting.

@ultimape experienced performance problems when opening ouronote in multiple tabs. In addition to performance issues on the machine which had multiple tabs open, other devices on the local network may have stopped synchronizing entirely until the additional tabs were closed. This issue should be expanded on, as this is only my understanding of the problem.

Intermittent. New set()/put() calls will occasionally stop working. Most often, incoming changes will be heeded but no local changes will be. Websocket disconnects are a likely culprit, as it seems having a disconnected peer causes this issue. Ideally, solution is implemented in GUN itself, but in the mean time, we at least need a way to ensure data integrity for local modifications. Perhaps a second instance of gun using localstorage or a separate indexeddb schema, using gun's in/out adapter properties to link the relayed & local gun instances.

see title

Currently, sharing a board requires setting up a certificate and sending a link to the board to the desired user outside of ouronote. This should be a more concise process.

Add support for text areas, at a minimum, this should include:

• Adding a text box with predefined text
• Editing existing text boxes

Self-explanatory. The pan tool is practically seizure-inducing.

This is probably due to a tool event firing immediately after the scrollBy() call in the previous event handler. Look to ononote for the solution.