nsreed / ouronote Goto Github PK
View Code? Open in Web Editor NEWReal-time collaborative whiteboard web app built with Angular, GUN, and paper.js.
Real-time collaborative whiteboard web app built with Angular, GUN, and paper.js.
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:
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.
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!
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.
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.
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.
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.
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.
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.
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
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
Pen input lag is too high to be useful for handwriting.
We want to think about development processes related to contributions / pull requests etc. So
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.
@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.
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.
Needs more testing.
see title
Add support for text areas, at a minimum, this should include:
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.
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.
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.
You should be able to copy/paste selected items.
It would be nice if this could use the system clipboard.
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).
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.
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.
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.
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.
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.
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.
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.
I want to be able to edit properties for selected items, such as:
Need a color swatch. It should store colors in a way that can be easily recalled for stroke/fill color selectors.
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.
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).
You should be able to clone selected items. Cloning them should create a copy in-place, and select the copy.
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.
It would be nice to have a tool that selects a color from the canvas and applies it to the current style
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.