Behind FlashPaper

[dehlirious]

I'm interested in the development journey of FlashPaper. I have a few questions that I hope will spark a meaningful discussion.

What inspired the creation of FlashPaper?

Could you clarify the roles of the most notable contributors, such as 'barry-smithjr' and 'mattburchett'?

What are the key factors you consider when assessing the project's success?

Are there any planned updates to enhance, add to, the UI?

Can you share any user feedback that significantly influenced the project's direction?

How open are you to adopting a class structure? (Would that go against the rational of retaining simplicity?)

How does FlashPaper position itself against alternatives like PrivateBin? (I'm well aware of the differences but I'd like your stance)

What functionalities from PrivateBin or other projects in this realm do you admire?

How do you prioritize simplicity versus adding new functionalities? (How important is simplicity in the design of FlashPaper)?

Considering the last functions.php update was three years ago, is there an interest in adding new features/changes, or do you prefer to maintain the current state under the philosophy “if it isn’t broken, don’t fix it”?

I'd like feedback on the idea of features like (additional) password protection, expiration options(instead of view once and delete), and the potential for multiple URLs per shared secret (e.g. if you want to share the same resources to multiple people. cons being data duplication in the db, limits would have to exist), having an ip(hashed, or other alternative) rate limiting functionality(one ip doing 33993 notes in a week is pretty sus for example) -- going against that, hashed or not(even with other alternatives like using password_hash on a hash or something) would technically go against the concept of zero knowledge. Also, the idea of expiration date if unread , set by the individual that is creating the note. (potential example for importance being, you wouldn't want to send a note to a friend, him being arrested without you knowing, having the police go through his texts a week or month later to find that note and have access to it)

Have you considered implementing any form of analytics for admins, e.g. total notes stored, notes created this month, etc (beyond very simple, non descriptive stuff, it'd be too against the fundamentals of being 'zero-knowledge', even this one example technically breaks that rule)

Switching, or having the instance settings being able to define, usage of alternative encryption methods. (Haven't actually thought into this one, so no particular, that would definitely be immediately supported without major rewrites, alternatives come to mind)

What has been the biggest thing learned(if any) through the development of FlashPaper?

What inspired the name "FlashPaper,"

And, last one for now, openness for a dedicated api endpoint? (depending on instance settings, allow all, with api-key only, etc) - current implementation has no issues but in my mind, I can see things being taken a step further) - also additionally, I'm aware it's been mentioned to a degree in the past but api being capable of decryption (this can come with cons but, implemented correctly can be fine)

I'm interested in contributing if I have the time but have seen instances where repository owners were not interested in new ideas or functionalities that didn't align with their vision. Understanding the boundaries/Mindset of the author is essential.
And let's be honest, as it sits, this project needs nothing. But it Could have more. I don't know if that's a path you want to take though, nor the boundaries of things you just simply wouldn't care for adding

[AndrewPaglusch]

Hey @dehlirious, I've answered your questions inline below:

What inspired the creation of FlashPaper?

FlashPaper was created to meet a need. I run an IT consulting company and needed a way to securely share secrets (like passwords, credit card numbers, etc.) with my clients. This motivated me to build FlashPaper.

Could you clarify the roles of the most notable contributors, such as 'barry-smithjr' and 'mattburchett'?

Both are close friends of mine. Barry helped a few years back with some web design components of the project. Matt has helped with various parts of the project as needed. They don't have any assigned roles.

What are the key factors you consider when assessing the project's success?

Security is my biggest measure of success. People trust FlashPaper with their secrets, so safeguarding them is my top priority. If secrets remain secret, I consider that a success.

Are there any planned updates to enhance, add to, the UI?

There are no set plans for UI improvements, but I recognize it could use some polish. I've been improving my CSS/Bootstrap skills with a SaaS project I've been busy with for the past few months. I might consider fixing some UI parts of FlashPaper when I get the time. I'd also welcome any PRs.

Can you share any user feedback that significantly influenced the project's direction?

Occasionally, I get an email from an individual or business expressing their love of FlashPaper. This motivates me to keep the project maintained. I haven't received any feedback that significantly influences the direction of the project.

How open are you to adopting a class structure? (Would that go against the rational of retaining simplicity?)

I'd be open to moving to an OOP/class structure. When I initially created FlashPaper, I felt that a functional pattern would be sufficient.

How does FlashPaper position itself against alternatives like PrivateBin? (I'm well aware of the differences but I'd like your stance)

FlashPaper's goal is to be as simple to set up and use as possible - both for the person/company hosting it and for the user. I try to keep everything as simple as possible while making it as secure as possible, by default and with little effort.

What functionalities from PrivateBin or other projects in this realm do you admire?

Good question. I really like the idea of doing the crypto client-side. This is something I want to implement when I find the time. I've already written most of the code (for another project). I just need to implement it into FlashPaper and figure out a way of migrating to client-side crypto without breaking existing secrets in the database, as well as the API. I believe PrivateBin and other projects do this already.

How do you prioritize simplicity versus adding new functionalities? (How important is simplicity in the design of FlashPaper)?

Simplicity is second to security. New whizz-bang features are not important to me.

Considering the last functions.php update was three years ago, is there an interest in adding new features/changes, or do you prefer to maintain the current state under the philosophy “if it isn’t broken, don’t fix it”?

This is very much a "if it isn't broken, don't fix it" philosophy. FlashPaper is secure and works very well. I've found no need to modify the core components of the project.

I'd like feedback on the idea of features like (additional) password protection, expiration options(instead of view once and delete), and the potential for multiple URLs per shared secret (e.g. if you want to share the same resources to multiple people. cons being data duplication in the db, limits would have to exist), having an ip(hashed, or other alternative) rate limiting functionality(one ip doing 33993 notes in a week is pretty sus for example) -- going against that, hashed or not(even with other alternatives like using password_hash on a hash or something) would technically go against the concept of zero knowledge. Also, the idea of expiration date if unread , set by the individual that is creating the note. (potential example for importance being, you wouldn't want to send a note to a friend, him being arrested without you knowing, having the police go through his texts a week or month later to find that note and have access to it)

These feature suggestions are solid, and I've actually considered many of them already. Unfortunately, they tend to conflict with my commitment to simplicity and zero-knowledge. The nature of maintaining a zero-knowledge system does indeed open up potential for abuse, but thankfully, we've managed to steer clear of any significant issues so far. I have monitoring configured on the server hosting flashpaper.io and I'm ready to ban any IP that starts causing trouble or affecting the site's availability. While I've thought about adding some privacy-conscious captchas to fend off bots, I really don't want to compromise the smooth and straightforward experience that users love. So, for now, I'm holding off on anything that could make sharing secrets less user-friendly.

Have you considered implementing any form of analytics for admins, e.g. total notes stored, notes created this month, etc (beyond very simple, non descriptive stuff, it'd be too against the fundamentals of being 'zero-knowledge', even this one example technically breaks that rule)

I am against any form of analytics in the project, as that would go against the zero-knowledge focus. The creation date/time of secrets isn't stored with the notes, so the most I can ascertain from the database is the number of secrets currently stored (which can be done with a simple query: SELECT COUNT(*) FROM secrets;. We're at just under 6k right now on flashpaper.io!)

Switching, or having the instance settings being able to define, usage of alternative encryption methods. (Haven't actually thought into this one, so no particular, that would definitely be immediately supported without major rewrites, alternatives come to mind)

In order to remain simple, easy to host and use, and secure, FlashPaper is opinionated and only uses known secure algorithms and configurations. There are already a number of options that admins can modify to change various settings of FlashPaper without compromising on security.

What has been the biggest thing learned(if any) through the development of FlashPaper?

I've learned a lot through this project, but nothing significant enough to mention. It's mostly about how to manage a popular project and keep things stable for the users - how to never surprise the user.

What inspired the name "FlashPaper,"

It's named after 'flash paper,' a type of incendiary paper that could be used for secure note sharing and offers fast, easy, and total destruction after being read.

And, last one for now, openness for a dedicated api endpoint? (depending on instance settings, allow all, with api-key only, etc) - current implementation has no issues but in my mind, I can see things being taken a step further) - also additionally, I'm aware it's been mentioned to a degree in the past but api being capable of decryption (this can come with cons but, implemented correctly can be fine)

The API was also created to meet a need of mine. I have an alias on my computer called fp that will POST a secret to flashpaper.io and return the retrieval URL. As far as I'm aware, nobody else uses the API. I don't believe I've been asked by anyone yet to expand it. Since it meets my needs, I haven't invested any time into building it out any further, but I'm not opposed to this.

I'm interested in contributing if I have the time but have seen instances where repository owners were not interested in new ideas or functionalities that didn't align with their vision. Understanding the boundaries/Mindset of the author is essential.
And let's be honest, as it sits, this project needs nothing. But it Could have more. I don't know if that's a path you want to take though, nor the boundaries of things you just simply wouldn't care for adding

I'd be happy to welcome a new contributor. Hopefully, my answers above align with your views. Feel free to pitch any ideas you may have here, and I'll let you know if it's something I would be open to implementing or merging. Thanks!

[dehlirious]

I'm too sluggish to be able to respond properly at the moment, the snippet I chose to focus on tonight was: UI design as it took the least brain power.

It could be cool if there were a few templates for the admin to pick from, to have their instance use. Therefore nobody is stuck to any singular design.

Here's what I made as a trial run. Design isn't particularly my strong-suit but its mobile/desktop compatible.

• Bootstrap 4.6.2
• Font-Awesome(not necessary)
• Google Fonts(Also, not truly necessary))

Screenshots

For reference, this holds the changes. May not be up to date if I make further changes.

I'm thinking:

• I like the idea of the navbar but it could also entirely be removed, not to mention the other pages would have to be designed prior to even needing one. I could see a point to a "FAQ" page, the others I merely used as placeholders.
• I'm not sure about the blue. Allowing instance-admin to pick different color schemes or to allow specific color hex's is a better idea than having static colors in my eyes.
• I may try out other color schemes, see what looks alright and make a preset list to pick from.

The design seems alright in my eyes though. What are your thoughts?

I also may end up circling back to the idea of multiple templates, having this as template1 and design another, potentially using a different css library (or try and use no libraries at all). I'm also wondering if this idea is worthwhile, may branch off and focus on another aspect instead before circling back to it.