Contributing Master Page

Hey, thanks in your interest for helping out. This project depends on people like you to flourish and grow. Through your work, you can play a large role in the direction of where BitGlitter goes.

This page should give you a starting picture of what can be improved on BitGlitter. Check out the other pages on this Wiki as well, if you want a better understanding of how everything works. We have Discord server that serves as the nerve center for communication, coordination, and planning. Come check us out, and feel free to ask questions!

Your input is greatly appreciated to me. If you have any ideas, suggestions, new areas of improvement, just general questions or comments, don't hesitate to get in contact. Discord is your best bet to get ahold of me quicker, otherwise my email is on my profile name here at Github. With that said, let's dive in.

Philosophy

• Make BitGlitter's code easy to understand- This is not only for contributors, but for newer programmers wishing to understand how everything works.
• Fail fast, fail early- Parameters out of range can cause BitGlitter to fail. Rather than crash in the middle of a longer process, all parameters are verified at the beginning, saving time and frustration for the end user.

How you can help

• Help improve the code- This is the primary way you can help, which is most of what this project is about, naturally.
• Write/rewrite documentation- If there is a new feature not yet currently documented, or perhaps some existing functionality could use a better explanation, this is where you come in. It is a crucial part of the project.
• Design/illustration/video editing expertise- This is all about putting a prettier wrapper over what we have, and having the project appear more polished will continue to attract more people to contributing, as well as using the product. Improving existing illustrations, or adding new illustrations where you think they would help is one way you can help in this field. Another way is by using your expertise in video editing to help put together a nice Youtube video outlining the project, its capabilities, etc. If you have any other ideas that you think can help the project, let me know!

All contributors will be credited on the front page readme for BitGlitter, as well as an optional hyperlink to a personal email address, personal website, or github page if you desire.

Master list of tasks to accomplish:

Major Goals

By increasing capabilities and ease of use, BitGlitter will continue to grow as a project and make a larger impact. These are larger goals that will represent milestones in it's development.

• Graphical User Interface- Utilizing a GUI framework such as ElectronJS, this would make BitGlitter much more accessible for a greater number of people, no longer requiring some proficiency in programming to use it.
• Read streams directly from the browser- As it stands currently, you need to have the file 'physically' on your drive in order to decode the data. Through a browser plugin or other means, this would give the ability to decode streams directly from what you see on the screen. This will make sharing content via BitGlitter far more convenient and efficient.
• Partial screen streams- Streams currently occupy 100% of the video space. This would allow streams to be overlaid on other videos, as a footer at the bottom of the frame, or an icon in the corner, or any other shape.
• RSA encryption- The only encryption option currently available is AES-256. This would add all RSA functionality into BitGlitter (encrypting with keys, signing streams, verifying streams by comparing signature with public key, etc).

Low hanging fruit

• Automatically download ffmpeg- Instead of needing to download it manually at library installation, the program achieves this automatically when first ran.
• Move config.pickle to config directory- It is currently outputting in root folder.
• Enhanced frame options- Specifically referring to single frame streams. Add the argument for if there's any blank space in the image to crop that out.
• Add ability to toggle saving statistics- As it stands, all write() and read() cycles send data directly to the Statistics object in configobjects. Adding a bit more functionality to this would be nice.
• Utilize pipelines in video creation- ffmpeg has some functionality called a pipeline that allows you to feed images directly into this function, so you can create a video frame by frame as each is created. As it works currently, each frame is saved as a .png in a temporary folder, and then they are fed all at once into ffmpeg and then deleted. Implemented this would reduce the amount of space the write process consumes, as well as increase speed of video rendering by 1.2-1.5x.
• Fix FPS issue with ffmpeg- If values other than 30 or 60 are inputted, I've noticed video stuttering, and frames are displayed at uneven durations. I don't know what the cause is (yet). Fixing this would allow custom framerate values, as for now, videos can only be 30 or 60 FPS.
• Add ability to run BitGlitter with command line arguments- This will further increase convenience and ease of use.

Performance

• Persistent state through unexpected stops- If the program abruptly while handling data, it may corrupt what is being worked on (partial saves), or waste the work on partial jobs (write()). This would allow BitGlitter to resume where it left off, without any loss of data.
• Introduce multiprocessing- BitGlitter is currently a single core process. This would dramatically speed up usage.
• Start moving parts of heavily-used to code to C- Excluding 3rd party libraries that assist with some tasks, everything done is with pure Python. This would speed up processing by orders of magnitude.

Stream Safety & Security

• Reed-Solomon Error-Correcting-Code- Adds a new layer of resilience to frames, making them more durable to corruption by using error correcting code within the stream. As it currently stands, a single corrupted block invalidates the frame. While it's nice to have that protection, it could be too heavy handed if most/all of the information can still be acquired.
• File Packaging overhaul- While filepackager does the job for now, there could be a better way for how to package files. Adding a manifest to the header along with filesize and SHA-256 would be good. Perhaps by packaging, compressing, and encoding files individually, we can allow the reader to retrieve the encoded files while still partially through the stream.
• Explore other possibilities with creating more secure streams- Perhaps frames can be linked together via blockchain. We'll think about ways malicious actors can corrupt frames/streams and take steps to fix these problems. With the exception of optional payload encryption, all frame headers are unencrypted. Maybe this is an area that can be improved upon.

Usability

• Presets- As it currently stands, you need to adjust every value to get what you want. By having a small handful of both image and video options, it will help expedite and simplify the write process for users who are new or are just impatient.
• Display stream information and project name in stream- This is a broader push for a few different directions- title screens, and in-stream information. Currently, unless you read the stream, you have no idea what's in it (or perhaps even what you're seeing!). A title screen would be a frame or frames displayed during the first few seconds of a video, showing stream name, description, files present, and other metadata. In addition, it will say this is a BitGlitter project and some brief explanation of what it is, as well as a link to the project. This will not only help BitGlitter users quickly identify what the stream is, but will direct newer users unfamiliar with the project to the main page. In addition to a title screen, another possibility is allowing these same text in some corner of the frame. This can apply to videos and images. It can be the BitGlitter logo along with meta-information, or whatever is agreed upon. Both of these options would probably require changes to the protocol in order for the reader to know what frames or regions of the frame to omit. The upside to doing this would be more quickly identifying what the stream is, if this option is enabled in write().

Miscellaneous

• Unit tests- These are very much needed, as this is now a community-driven project. All tests belong organized in the tests folder.

Future possible ideas to implement

Have a cool idea? Let me know and I'll add it to this list.

• Audio channel introduction- Introduce audio as an additional datastream, either to be used along with a video stream or by itself.

• Seamlessly tie download links to streams online- Click a download link, and behind the scenes your client will be directed to a stream hosted somewhere, which upon completion and verification will download the file.

• Custom color server- Custom palettes flagged as 'public' get uploaded to a server. If a palette is unknown by the client, it can automatically download them.

• Geometry revisit- BitGlitter will move beyond just squares for ‘pixels’ (individual blocks in the frame), and will experiment with other shapes. Allow spacing between pixels for transparent effects on partial screen streams. Explore possibilities of other aesthetic effects.

• Dynamic frame parameters- This would make partial frame streams no longer constrained to a static location on the screen. This means you can created animated shapes that contain the stream inside of it. For instance, the blocks draw out an outline of a person, a plane, or an animal can move across the screen, so the stream is inside of that object. While it’s purely for aesthetic benefit, it will be a strong feature that will allow it to be embedded in far more novel, fun ways.

• Seamlessly tie download links to hosted streams- Just as how magnet links open a torrent client, download links can take you to a stream which will run BitGlitter in the background and automatically download the file.

• Allow hosted streams to act as BitTorrent seeds- Through a modified torrent client and protocol, a stream can act as a seed for a torrent. Torrent "chunks" would translate to specific frames without the BitGlitter stream.