Pre-register a downtime

#1

I have summarized my thoughts, what do you think about these

  1. Requirements for Maintenance Announcement**
  • Pre-registration of downtime: The node operator must register the planned downtime in the system (e.g., the ThreeFold Dashboard) at least 72 hours in advance.
  • Automatic notifications: The system sends a notification to all current renters of the node.
  1. Workflow for Maintenance Announcement**
    a) Node Operator Registers Downtime
  • Example: The operator plans maintenance on January 15th from 02:00 to 05:00 UTC. In the dashboard, they provide:
    • Node ID: NODE123
    • Downtime period: 15/01/2025, 02:00–05:00 UTC
    • Reason: Hardware upgrade
  • These details are submitted to the ThreeFold backend system.

b) System Validates Downtime

  • The system checks if the node is currently rented:
    • If not rented: The downtime is immediately approved.
    • If rented: A notification is automatically sent to the renter.

c) Notification to the Renter

  • Content of the notification:
    • Node ID: NODE123
    • Planned downtime: 15/01/2025, 02:00–05:00 UTC
    • Note: “Please secure your data in advance, as the node will be unavailable during the maintenance period.”
  • Example:
    • Email or Push per TFT app to the renter:
      Subject: Maintenance Notification for Your Rented Node (NODE123)
Dear Customer,

Your rented node (NODE123) will be offline on January 15th, 2025, between 02:00 and 05:00 UTC 
due to a scheduled hardware upgrade.   
We recommend securing your data before the maintenance begins.

Thank you for your understanding.

Best regards,  
The Farmer 123

3. Reward for Timely Announcement

  • Condition: The maintenance must be announced at least 72 hours in advance.
  • Reward for Operators: The node operator receives partial rewards for the planned downtime (e.g., 50% of the usual earnings).
  • Example:
    If a node typically earns 10 TFT (ThreeFold Tokens) per day, the operator would still receive 0.625 TFT for 3 hours of downtime (10 ÷ 24 × 3 × 0.5).

4. Consequences of Missing the Deadline

  • Unannounced downtime:
    • The operator does not receive rewards for the downtime.
    • The renter may request compensation.
  • Automated warnings: The system can send reminders to operators about upcoming deadlines for planned maintenance.

5. Centralized Dashboard for Renters
A centralized dashboard displays all upcoming maintenance and allows renters to take action:

  • Example:
    Scheduled Maintenance:
- NODE123: 15/01/2025, 02:00–05:00 UTC (Hardware upgrade)

Summary

  • Node operators must register planned maintenance at least 72 hours in advance.
  • Renters are notified promptly to secure their data or prepare for downtime.
  • A reward system incentivizes operators to plan downtime responsibly and transparently.

This approach minimizes disruptions, builds trust, and ensures operational efficiency in the network.

3 Likes
#2

Great post. Thanks for writing this and pondering about how we can improve farmers+users UX of the platform.

It has been discussed in the past but we never implemented something like this. There are many ways to go forward, and it could be done in steps, so we achieve a minimum viable product, and then expand from this.

Some ideas:

  • I’d first propose a voluntary system, where farmers and users can register, farmers can send message to all their subscribes users and state if there are downtime planned, and users can send messages to the farmers hosting their workloads if there are issues (2-way communication channel between farmers and users)
    • We could set some Telegram bot as a basic proof-of-concept/starter
#3

Proposal: Implementing a Phased Communication System for Farmers and Renters
To improve transparency and collaboration between farmers and renters, I propose implementing a communication system in three phases. This approach allows for gradual adoption and ensures the system evolves to meet the needs of all stakeholders.

Phase 1: Voluntary Registration for Farmers and Renters
Description: Farmers can voluntarily register their nodes through the UX interface and connect to a communication bot (e.g., Telegram, Twitter bot). Renters can also subscribe to this bot to receive updates about the nodes hosting their workloads.

Functionality:

Farmers send planned downtime announcements through the bot.
Renters receive notifications about downtime or other issues affecting their workloads.
Potential Drawbacks:

Participation is voluntary, so some farmers might not engage.
Lack of accountability could negatively impact renters relying on uncommunicative farmers.
Phase 2: Mandatory Downtime Reporting with Notifications
Description: Farmers are required to report planned downtime through the UX interface. Notifications are then sent automatically to renters via a communication channel (e.g., bot, email, or app).

Accountability Measures:

If a farmer does not report downtime while a renter’s contract is active, the farmer will face penalties, such as receiving a negative mark in their profile.
Benefits:

Ensures renters are informed of potential disruptions.
Encourages farmers to maintain transparency and reliability.
Phase 3: Advanced Downtime Management with Renter Options
Description: Farmers report downtime via the UX interface, and renters receive notifications with three options for managing the disruption. If the renter does not respond within a given timeframe, the farmer may proceed with the downtime according to their preferred option.

Proposed Options for Renters:

Accept the downtime: Renters agree to the planned downtime as communicated.
Request migration: Renters can choose to migrate their workload to another node (if available).
Request compensation: Renters can ask for a partial refund or token compensation.
Accountability Measures:

Farmers who fail to report downtime will:
Receive a negative mark in their profile.
Be subject to TFT deductions in the following full month as a penalty for failing to comply with the rules.
Benefits of the Phased Approach
Gradual Adoption: Each phase builds on the previous one, allowing stakeholders to adjust to new requirements without overwhelming changes.
Transparency and Trust: Renters gain confidence in the platform through clear communication and accountability measures for farmers.
Fairness: The introduction of penalties for non-compliance ensures fairness for renters while motivating farmers to follow best practices.
Flexibility: Renters are given multiple options in Phase 3, empowering them to choose how downtime is managed.
Conclusion
This phased approach ensures a balanced and structured implementation of the communication system. Starting with a voluntary model in Phase 1 allows for testing and refinement. As the system matures, mandatory reporting and renter options in Phases 2 and 3 will strengthen the platform’s reliability, foster trust, and improve the overall experience for both farmers and renters.