I’m George from Langmeier Software GmbH, known for advanced backup solutions. Inspired by Storj’s successful integration with Nextcloud, which beautifully combines data security with efficient collaboration, we at Langmeier are eager to explore a similar partnership that leverages your decentralized storage expertise to revolutionize how backups are secured and managed.
Why this partnership could be a game-changer:
Shared Goals: Like the Nextcloud collaboration, Langmeier aims to enhance the privacy and integrity of data backups using Storj’s decentralized network.
Innovative Integration: We propose combining Langmeier Backup’s robust features with Storj’s secure network to create a backup solution that is not only secure from data breaches but also efficient and scalable.
Community and Growth: This partnership could serve as a model for future integrations, showcasing the practical applications of decentralized storage in critical data management.
Proposed Steps Forward:
Technical Exploration: Discuss potential technical integrations and infrastructure needs to ensure compatibility and security.
Joint Development Initiative: Like Storj’s approach with Nextcloud, co-develop features that cater to specific backup needs, such as automated data redundancy checks using blockchain technology.
Community Engagement: Share developments regularly in forums like this, gathering feedback and iterating on the community’s insights.
We Seek Your Input:
What are the primary concerns you see in integrating decentralized storage with backup solutions?
How can we ensure that such an integration remains user-friendly and accessible to non-technical users?
Are there particular security features from the Storj network that you think would be most beneficial for a backup solution?
Conclusion: Drawing on the precedent set by Storj and Nextcloud, we believe a partnership with Storj could significantly advance how backups are perceived and implemented across industries. We are excited about the potential and eager to dive deep into this discussion with you all.
Thank you for considering this opportunity. I look forward to engaging with you and discovering how we can achieve something great together.
Thank you for your interest in partnering with Storj. Please review our partnership offerings by going to https://storj.io and then choosing Partners from the top menu. There will be a link to contact our partnership team to discuss your proposal, or you can directly ask for setting up a meeting at https://storj.io/contact-sales
We are looking forward to getting in touch with you!
If Langmeier Backup supported Amazon’s S3 API… I think technical integration would be “done”? Then perhaps it’s a business discussion if they can resell Storj under-the-hood for some margin… instead of capacity in their own Langmeier Backup 365 cloud storage?
From a client’s point of view, I would consider data encryption both in-transit and on-disk as number one on my concern list. Thankfully this is taken care of by Storj’s way of operating.
From a user’s point of view, I would think that providing a GUI for easy file/folder selection to backup is necessary. When setting up the remote backup to Storj, I would expect the software to show a warning to the user that the passphrase used is the only thing that can decrypt the files on the network, so it should offer a way for it to be stored in a cold-backup, ie on a USB disk. Usually when companies use a product that has a credential requirement, those credentials are only known by the people that use the product. 10 years down the line when that person leaves the company, the company usually ends up trying to get those credentials back.
After setup and backup of the passphrase, the software should show a list of folders/files on the computer so that the user can easily select what to backup and at what interval, then off it goes to do the actual backup. This backup should be using Storj’s uplink (or integrated library?) so that the backups don’t have to flow through a centralized S3 gateway, and can be performed directly from the client’s PC to the Storj network.
The most important things are already taken care of by the way Storj stores data. Data is encrypted and erasure coded, so privacy is already handled, as well as bit-rot. In case of Storj node failures, the network can self-heal without any interruptions to the user.
Interesting…
Storj offers many different ways of integration and it depends on your company what you are willing to offer.
Technical integration can be done via S3 Gateway or better via integrating Uplink into the product. As user I’d wish you offer both. Uplink has the advantage to locally encrypt and makes better use of parellelism.
The S3 Gateway does server side encryption but does not have an expansion factor when uploading. We have learned that there are companies who make use of both: Uploading vie S3 downloading via Uplink.
As user it would be great if I could choose the method to use.
As for access to my backups again it depends on what your company is willing to offer.
The most convenient solution would be that I can upload my backups in a bucket that your company provides. Then I do not have the hassle to sign-up with Storj and manage that account and passphrases. In that case your software would have to manage that my backups are encrypted, not visible/accessible by others etc. and your company would bill me according to my usage.
But as a privacy focused user I may like to use my own Storj account, buckets and passphrases and I would expect the software to help me manage that locally, especially the passphrases so they do not get lost and I lose access to data.
Also there are some Storj features, that are likely interesting for more advanced users or users with specific needs: Geofencing and Storj managed passphrases.
When a user has his own Storj account then he can make those settings as he likes and the software could be dumb. If the users is uploading to a Storj account / bucket not controlled by him, the software should help to make upload the way he wants. E.g. you company could offer EU/US only buckets → the user should be able to select those, or you company sets a bucket as passphrases managed by Storj → the user might want to avoid those.
Another interesting feature is maybe the TTL were I can set an expiry date for uploaded data. When I have a working backup plan the software could support it that backups get automatically deleted after some time.
As a user of course I want my backups to be and remain encrypted at all times and accessible only by me. Recovery, e.g. downloading should be very fast. Backup data must be verified and working once downloaded 100%. Running backups should be 100% automated and complete without errors.
Thank you all for your valuable feedback and insights regarding the potential partnership between Langmeier Backup and Storj. I appreciate the detailed responses and suggestions.
I have another question for the community: Has anyone had experience with Lighthouse Storage? I’m interested in learning more about its capabilities and how it compares to Storj in terms of decentralized storage solutions. Any insights or experiences you could share would be incredibly helpful.
Thank you for your insightful feedback. Indeed, supporting Amazon’s S3 API could streamline the technical integration significantly. This could allow us to resell Storj under-the-hood for some margin, leveraging their decentralized storage network instead of relying solely on our Langmeier Backup 365 cloud storage.
Regarding your point, I wanted to explore a few more details:
Decentralized Storage Incentives: One interesting aspect we’re considering is allowing Langmeier Backup users to share a portion of their disk space for backups of other users in a peer-to-peer network, similar to Napster’s model but with encrypted data. Users would earn blockchain-based coins as an incentive. Do you think this model could align well with Storj’s existing infrastructure? Are there any specific challenges or advantages you foresee with this approach?
Reselling Storj Services: From a business perspective, how feasible would it be for Langmeier to bundle Storj’s decentralized storage solutions and offer them as part of our backup service? What pricing models and margin structures have worked well for similar integrations, if you have any insights on this?
Looking forward to hearing your thoughts and continuing this exciting discussion.
Thank you so much for your comprehensive and insightful feedback. Your points about data encryption and user-friendliness are spot-on and align closely with our priorities for integrating decentralized storage solutions.
Data Encryption: It’s reassuring to know that Storj’s operating model addresses both in-transit and on-disk encryption. This is crucial for us, as ensuring our users’ data privacy is a top priority.
User-Friendliness: You’ve highlighted a significant aspect - the need for a user-friendly GUI. We’re considering implementing a feature where users can easily select files/folders to back up and receive warnings about passphrase management. Your suggestion about offering a way to store the passphrase securely, like on a USB disk, is excellent. Ensuring users don’t lose access due to forgotten credentials is vital for long-term data security.
To delve deeper, I’d love to get your thoughts on a couple of points:
Passphrase Management: Beyond USB storage, do you have any suggestions for other secure and user-friendly methods to manage and recover passphrases?
Decentralized Data Management: Given your expertise, how do you see the balance between using centralized S3 gateways and decentralized uplink approaches in terms of performance and security for end-users?
Your input is incredibly valuable as we work towards creating a seamless and secure backup solution. Looking forward to hearing more of your expert insights.
Thank you for pointing that out. I’d love to hear more about your experiences and insights on this matter. Specifically:
Could you elaborate on the differences in security and performance when using the public S3 gateway compared to running your own gateway or using the native protocol?
Do you have any additional advice or remarks on best practices for integrating decentralized storage solutions, particularly concerning maintaining security and efficiency?
Thank you for your input. It’s good to know about the subset of S3 features implemented by Storj. Have you ever worked on a similar integration before? If so, could you share some insights or experiences from that process?
Also, what specific challenges or advantages did you encounter when dealing with the subset of S3 features on Storj? Your expertise would be incredibly valuable as we navigate this integration.
Thank you for your comprehensive feedback and insightful suggestions. It’s great to see such an engaged and knowledgeable community here.
We are definitely considering the flexibility of offering both S3 Gateway and Uplink integration to cater to different user needs. Your point about local encryption and better parallelism with Uplink is well noted. Providing users with the choice to upload via S3 and download via Uplink could indeed enhance flexibility and performance.
Regarding access to backups, we are evaluating both options: managing user backups on our end for convenience and allowing users to handle their own Storj accounts for enhanced privacy. The idea of offering features like geofencing and managed passphrases is intriguing and aligns well with our commitment to user security and customization.
The TTL feature you mentioned, where backups are automatically deleted after a set period, could be a valuable addition to our backup solution, especially for users with specific data retention policies.
A couple of follow-up questions for you:
Have you seen any common pitfalls or challenges with other integrations that used both S3 Gateway and Uplink? Any lessons we should keep in mind?
How important do you think it is for enterprise users to have features like geofencing and managed passphrases compared to regular users?
No, sorry, I’m only a lowly node operator. I do use AWS S3 at work, which is why I even know about these features. I’d love to use Storj to build something real, unfortunately the use cases I am working on now (low-latency big data processing with colocated compute resources) cannot be implemented with Storj.
If you use the public S3 gateway, then Storj has to have your encryption key, since the gateway would be encrypting and distributing the data to the nodes. Of course, you can additionally encrypt the data (with another key) before sending it to the gateway.
If you use the native uplink (or run your own gateway) then it encrypts and distributes the pieces itself.
Another concern would be the number of connections - using a gateway, you only need one connection to upload a file. Using a gateway would possibly have slightly higher latency (not that it would matter for backups). OTOH, using uplink, you open 110 connections to the nodes - it may be a bit faster (because usually multiple TCP connections perform better than one), but some consumer routers may not be able to handle the number of connections.
Thank you for your honesty and for sharing your experience with AWS S3. It’s always great to hear from passionate individuals who understand the intricacies of these technologies. @Toyoo
While I understand your current projects might not align with Storj’s capabilities, your insights could still be incredibly valuable to us. If you’re open to it, I’d love to stay in touch and possibly collaborate in the future as we explore new use cases for Storj.
Could you share your contact details via email? You can reach me at e.g.zbinden@langmeier-software.com. It would be fantastic to have someone with your enthusiasm and knowledge on board.
Thank you for the detailed explanation regarding the differences in security and performance between using the public S3 gateway and running your own gateway or using the native protocol. @Pentium100
I find your points on encryption key management and the number of connections particularly insightful. Managing encryption keys securely is indeed crucial, and the number of connections could impact performance depending on the network setup.
Have you encountered any real-world scenarios where these differences significantly impacted the performance or security of the backups? I’m curious to know if you’ve seen any specific cases or benchmarks that highlight these differences more clearly.
I do not use Storj or any other similar network, all my backups are on my hardware (its not all at the same place though). As I use older hardware (especially as the backup server), I found that double encryption (say, SSH over VPN) slows down the transfer a little bit. Since I am using VPN, I can use rsh or ssh with no encryption and get a bit better performance.
I am using zfs and my backups are done using zfs snapshots. It works great and allows me to do “incremental forever” backups where I only need to do a full backup once and then I can just copy the differences from one snapshot to the other, deleting old snapshots. It is great, but the downside is that the backup server has to have zfs and that means I cannot use Storj or similar even if I wanted to.
No, I am just a SNO and have no further insights. I was referring to the statement of Storjs COO in this video:
Check it out, it is quite interesting.
To use S3 gateway for uploads and native integration for downloads seems an interesting idea to be able to get fast uploads avoiding the expansion factor and fast downloads benefitting from erasure coding and parallelization. However using the Storj S3 Gateway means to use server side encryption. So you’d probably either let your customer choose if they want that or offer additional encryption of the backup before uploading. I believe you could also setup your self-hosted S3 gateway if you have the skills to manage it.
I believe geofencing is very important for users enterprise or private espescially in the EU. due to privacy laws. For enterprises there is the GDPR and private users are often also privacy minded and don’t want to store their data outside of the EU. With geofencing this can be achieved and only nodes within the EU get selected for uploads and storage. So it should be an important feature for companies that want to or need to meet that GDPR requirement.
Regarding managed passphrases you should again talk to Storj. It was their experience with customers that led to the development of this feature, it is still in development for example: Satellite-managed encryption passphrase: Remove encryption warning step during access creation · Issue #7020 · storj/storj · GitHub
I don't know the exact implementation, but I am generally not so fond of this feature as the whole idea about this web3 storage was that Storj does not know your passphrases and could not snoop on you or give 3rd parties access to your data even if they wanted to. With Storj managing passphrases for customers receiving court orders to check if the passphrases can be obtained from them seems inevitable. If your company decides to provide a Storj account or a bucket for your customers to upload their backups to it, you probably should be transparent about whether or not the passphrases to this bucket are shared with Storj.
