We are rebuilding our site, without a database, from scratch enabling anonymous and semi-anonymous slots on top of an honour billing system.
If you would like to be updated when we release new features in our roadmap below then please enter your e-mail address:
The Honour Billing System
All slots are now anonymous. We have no information tying their usage to a person. Embracing this, the honour system means:
- Slots are identified by the server and username.
- Anyone with the server and username can see some information describing the slot: allotted disk space, paid days remaining, and number of e-mail addresses tied to the slot (but not to view the e-mail addresses).
- E-mails can be added to a slot. They will be e-mailed on notification that we need your attention e.g., payment reminders, disk quota. Tied e-mails do not mean ownership of the slot.
- To begin with we lack basic information on slots: renewal dates and allotted disk space. We will ask for you to fill this in. Note: if you want a cheaper slot or more disk space, do it at renewal, not here.
- After, the slot may be renewed. You will be able to
specify how much and for how long you wish to renew the slot for. We will ask why and will be genuinely interested in hearing your reasons.
- We will keep the slot running until the date pledged.
- All payments can be fully refunded in the first seven days.
- Access to the slot (data, software, usage, etc) is done separately: via the SSH / SFTP / FTP password.
I believe that the honour billing system will be a great system in the long run because:
- Our customers can send a direct message when they want change: perhaps a support ticket didn't quite go as planned or something hasn't gone right over the month.
- We can offer free slots.
- It guarantees that we offer the lowest price, best value on the market.
Over the past week many have expressed their support for Feral and the new system and while it does have its risks, we intend to keep it around.
Our first goal is to gain feature parity with our old website given the new caveats. Now is the best time to send an e-mail asking for your idea to be implemented.
I plan on going through all features in the order presented. They will likely be amended and broken down as things progress. Please consider the descriptions as a stream of consciousness forming my decision making process—a mind dump without marketing polish. I have decided to forego estimates as they are stressful and inaccurate.
Features Working Towards Now
The following goals will bring the new site to feature parity with the old.
- Stripe: web hook
- A web hook allows us to update payment history immediately and is necessary for feedback.
- Fraud evaluation
- We must evaluate our anti-fraud to make sure we only process legitimate payments. This is a relatively unknown stage.
- Wiki (next generation FAQ)
- I will create a git backed Wiki that uses markdown. Risk: finding markdown evaluators in Erlang (or presumably I can handle it in JS). This will allow us to rebuild the FAQ to make them more useful to the current situation. I will also need to specify guidelines and categories to aid in its development.
- New slots
- By now the dust will have settled and we will be able to create new slots.
- I will either integrate Stripe or Coinbase. Many customers prefer Bitcoin as it's easier and ensures privacy. It is an important currency for the business. I will intentionally hold off integrating Bitcoin so that any bugs in the new payment framework can be addressed.
- Direct debits are important to us: cheaper, easier to use (can modify / cancel from bank account) and often the preferred payment method.
- Many have expressed interest in keeping Amazon Payments. There are two issues: (1) their anti-fraud isn't up to par and (2) it increases a dependency a business that I can't easily replicate elsewhere i.e., they are picked because of trust in Amazon's brand which gives them control over their captive audience allowing them to make decisions that hurt Feral. For instance they could shut down (like Google Checkout), unilaterally stop accepting our payments (like PayPal), or increase prices (as happened in March). I plan to integrate Amazon but with a +5% fee to cover the extra cost involved. This fee can be removed at will via the honour system and paves the way to adding other branded payment processors. Their API is a nightmare so integration might take a little longer.
Post Feature Parity Improvements
After we have reached feature parity we will continue forward by adding improvements. These are a mixture of big projects vs small site improvements and will be expanded as they're approached. In no particular order:
- One technical success of the previous website was having all data integrate into what was known internally as "feralapi". I will look at bringing this back in a distributed manner. This had a lot of hidden complexity which makes assessing the implementation difficult.
- Disaster planning assessment
- I will assess how all data is handled, stored, and protected. I will implement proper safeguards. Followed by a flogging for those responsible for this mess.
- External dependency assessment
- I wish to reduce external depedencies particularly where Feral has the resources to do things itself. This will help reduce future issues.
- Anonymous, semi-anonymous, non-anonymous slot distinction
- I would like anonymous slots to be: no e-mails and Bitcoin only. Semi-anonymous slots have e-mails associated (not as an owner) for notification and may pay with debit / credit cards although Bitcoin is encouraged. Non-anonymous slots are tied to a specific e-mail address (the owner) and enable features such as renewals. I need to find a better name than "non-anonymous" slots. This step will add the ability to associate slots behind a login.
- Front-end redundancy
- The front-end is not a redundant system but is integral to a lot of services. It depends on a non-distributed database for ease of programming. I will assess what work needs to be done to move to distributed databases.
- Core system redundancy
- There are other support servers that provide services we depend on, for example DHCP. I will double check their properly redundant.
- Network: VPN and IPSec
- I would like to implement a internal network that spans across all servers and slots. It will be accessible via OpenVPN and similar technologies separate from the slot servers. It will require co-ordination with the front-end server as I would be unlinking access from the slot server. Initially the first goal will be to secure access into our network however a second goal will provide more control on how it works as a traditional VPN (including port forwarding).
- Network: ddos protection
- One of the reasons for keeping www.feralhosting.com on an external network was to gain better ddos protection. I will assess what more can be done.
- Network: install 80x 10G DWDM ring
- Network growth depends on bringing this up. I am waiting on transceiver coders to reconfigure installed optics.
- Network: add 10G to London
- Signed for, almost ready, time to expand capacity.
- Network: bring additional exchanges online
- I have prepared agreements for additional connectivity across European exchanges. I will contact them to begin the connection process.
- Network: move to 100G switches at core
- Expand switching capacity in a better design and prepare the ground work for future improvements.
- Network: retire Miaow / Brocade router
- I will look to retire Miaow by moving its eBGP sessions to the core switches. This will boost routing capacity to several Tbit/s.
- Network: reroute
- The reroute page could be easier "just download this file to optimise".
- Network: IPv6
- It's deployed but not pushed. I should evaluate what IPv4 only functions still exist in the system and see what is required for its full use.
- Network: dedicated IPs
- I should automate their set up and management. They can then be purchased on the honour system. 100% of funds pledged should go to purchasing new IPs.
- Wiki: search
- Can it be improved? The FAQ was historically terrible.
- Payments: auto-renewal
- Starting with GoCardless I will set up an automatic renewal
- Payments: Alipay
- Stripe offers Alipay that is well-loved in China. Is it suitable for integration?
- Handle alternative curriences: GBP, EUR, USD and BTC. This may avoid fees at some banks and allows less worry over fluctuating exchange rates (also, who wants to hold GBP any more?)
- Privacy: private information
- When we lost our front-end server only e-mail addresses were on it. This was a fortunate precaution instead of trying to store everything that is passed to us. I wish to assess what meta-information is stored across all servers and set up a policy showing what exactly is stored, for how long and its justification. I need to think of ways to properly enforce and track this.
- Privacy: encryption
- Our front-end server should be encrypted. This won't protect against online attacks but will bring peace of mind knowing when it is offline.
- Business: lifecycle
- Whenever I have a bad customer support experience I evaluate on whether Feral would respond in a similar fashion. From memory, when we've shut down a slot, it has always been for an obvious reason "you were using it to launch denial of service attacks" which leads me to believe we may have never been in OVH's position taking down our server. I believe documenting all possibilities in a slot's lifecycle will help alleviate this. It will allow us to specify exactly what is happening to a slot was closed and possible recourse.
- Slot: meta information
- Clicking the server should provide you with more information e.g., the IP address, SSH fingerprint
- Slot: software restart
- I am an administrator and I think that logging via SSH is a daft idea. Why put my customers through it? I should implement software restart buttons. (SSH access will still be available though).
- Slot: change passwords
- I should evaluate the need for a proper method for changing passwords. The current system says "just reinstall" which is a simple method. This might be too complex (having to understand and change application state) and might take a different approach.
- Slot: extra software
- I should go through the FAQ / Wiki and look to automate installing the software.
- Slot: SSH web console
- This would make using the slot easier but might make everything a little more risky.
- Slot: uninstall software
- Remove it from the software page and slot.
- Software: rutorrent's feralstats plugin
- This small little plugin will probably need an API from Feral.
- Services: expand on offers
- All slots are currently sold by disk space (for both HDD and SSD). I should expand offers to specify cores, RAM and IOPS. This will allow customers to make a slot tailored to their exact needs. This will take a lot of work and investment as the design of the whole business is dependent on matching CPU and RAM to disk capacity although CPU and RAM are heavily over provisioned.
- Slot: disk redundancy
- We should offer a RAID1 set up for half the disk space on a slot.
- Slot: back ups
- We should offer integration of external back ups to customers in some fashion.
- Site: HTML / CSS
- I will need to improve the website to be more "reactive" and better cater to mobile users.
- I would like to offer much more real-time statistics on all servers and slots. It was never hidden but should be more accessible.
- Test coverage
- Having just rebuilt the main website, test coverage will not be 100%. I shall add more unit, integration and system tests where appropriate.
- Technical debit
- I have accrued technical debt in parts of the codebase.
Ideas Under Consideration
We like these ideas but they require more thought on their implementation.
- Darker themed site
- Someone has expressed an interest in a dark background website making for easier viewing at night time. There are a few ways to handle this: we implement a user setting to toggle an alternative CSS, custom CSS, or perhaps instructions to set up custom CSS in the browser. This request suggests something else: evaluating accessibility (e.g., blindness, colour blindness) and not just ease of viewing under different conditions.
These are the features / decisions that have been completed.
- Slot renewal
- We need pages to guide through setting the renewal date, specifying the allotted disk space, and then a framework for making a payment via a processor.
- Stripe: renewal page
- Stripe is a payment processor that handles credit and debit cards for us. It does not require a login and handles the majority of our payments.
- Stripe: history and refunds
- It would be great to present payment history for a card. This will provide feedback on previous payments and enable refunds to be completed.
- Support tickets
- Our old ticket system was beautifully simple: a text box for messages with staff handling managing things in the background. I will look to duplicate the old system. This is near the bottom because we need slot authentication to be worked out first. In the meantime e-mail has taken its place.
- Slot meta details
- The first part of the honour billing system requires pages to display what limited public information is available on a slot. This includes tying e-mails to a slot.
- Manage slot: disk usage
- Provide a means to get and update the current disk usage. I will forego displaying historic data at this point and aim to work on a better system for handling slot statistics at the post feature parity stage. This is an easy step: it is very similar to the software installs.
- Roadmap notifications
- The e-mails for roadmap notifications are being collected but I still need to create a small process to send them out.
- Manage slot: login as owner
- Providing the SSH / SFTP / FTP password is enough to say that you own the slot (you can do anything with it). I will need to evaluate the best way to confirm access dynamically and implement the check. This step will provide a login for more managed options on the slot.
- Manage slot: software
- Duplicate viewing and installing software from the old site (with no feature changes). This is an easy step: re-use existing install mechanism.
- Server commands
- Our slot servers are separate from the front-end where software can be installed. This communication has been updated to cater to the new needs of the site: the slot servers acting as the user database.
- Anonymous slots
- My original idea was to make an anonymous slot distinction from the outset. However this feels like the wrong abstraction as it complicates several pages while the site is being rebuilt. The database can still handle anonymous slots (as it has to right now) so I will revisit this implementation later when it is easier and can be made clear.
- Database model
- I have developed and tested a database model for all site features. Getting this right has been where the bulk of my development time has gone.
- Site framework
- Release of the current status (what happened?) and the roadmap (what's next).