TXTWRK

Storage Size	Price (£)	Description
5GB	Free	Initial allocation for content creation and posting
1GB	£100	Additional permanent storage pack
5GB	£500	Expanded legacy storage for creators or startups
10GB+	£1,000+	Full archival for heavy contributors, communities, or networks

⛶

OpenCompute; 🌎; AI; America; Announcement; Assets; Business; Challenges; Community; Data; Development; Global Change; History; In 1000 years; Investors; Learning; News; Servers; Technology; Work; Workspace; World
13:07 15/10/2026
Views: 24
Comments: 1

Documentation: Server: TXTWRK Servers

Technology

Neutral

TXTWRK Servers

Infrastructure Development & Feasibility Report

October 2026 | Concept & Research Edition
TXTWRK — https://txtwrk.com

> Imagine a TXTWRK Server switched on by someone in your family today. A hundred years from now, that same server is still running, still connected and still contributing to the network. It may have needed maintenance, upgrades and periods of downtime, but the network kept working while it rested.

Built to outlast generations. Designed to evolve.

Executive Summary

TXTWRK proposes a new approach to digital infrastructure, combining accessible home servers, simplified software, partner integrations and an optional distributed computing network.

The initiative has two principal products:

Product	Proposed Starting Price	Purpose
TXTWRK Server One	From £1,000	Home hosting for businesses and communities
TXTWRK Servers: Local Open Compute	From £3,000	Server One capabilities plus distributed computing participation

Prices are preliminary development targets, not confirmed retail commitments.

The network begins as a hybrid of residential nodes, traditional data centers, cloud infrastructure and content delivery partners. Over time, more workloads may be distributed when technically and commercially feasible.

---

Part One — TXTWRK Servers

1. Product Vision

TXTWRK Servers are plug-and-play devices designed to help people establish and operate businesses, websites and communities from home.

The product prioritizes user experience. Customers should be able to connect their hardware, complete a guided setup and begin using their server without specialist systems administration knowledge.

Core Principles

•Plug-and-play installation.

•Locally controlled infrastructure.

•Preinstalled server software.

•A simple local management interface.

•Optional integration with txtwrk.com.

•Access to partner applications and services.

•Security, updates and backup support.

•Long-term maintainability and repairability.

2. User Experience

The intended setup journey is:

1. Unbox the TXTWRK Server.
2. Connect power and networking.
3. Open the local setup interface.
4. Configure administrator access and security.
5. Optionally connect a TXTWRK account.
6. Configure domains, applications and services.
7. Launch a website, community or business platform.

The local interface should remain useful even when TXTWRK's central platform is temporarily unavailable.

3. Software Architecture

Layer	Function
Local interface	Device management, storage, applications and networking
TXTWRK platform	Accounts, domains, licensing, support and partner integrations
Partner services	Website builders, management panels, security and backup
Server operating environment	Hosting, containerization, updates and monitoring
Network services	Optional connectivity to the wider TXTWRK ecosystem

TXTWRK can investigate integrations with established software such as cPanel, open-source management tools and future applications created by independent developers.

4. Hardware Requirements

Component	Proposed Requirement
CPU	Efficient multicore processor
RAM	Expandable memory
Storage	SSD-based system and application storage
Networking	Reliable Ethernet connectivity
Security	Secure boot, encryption and authenticated identity
Cooling	Efficient, maintainable cooling
Power	Low idle consumption and safe shutdown
Construction	Repairable and replaceable components
Software	Preinstalled TXTWRK environment

Final specifications must be established through workload testing and manufacturing research.

5. Commercial Positioning

Proposed starting price: £1,000.

The objective is to provide accessible infrastructure for individuals, startups and communities.

The price is an initial target. Manufacturing costs, taxes, support, warranties and commercial viability remain to be validated.

---

Part Two — TXTWRK Servers: Local Open Compute

6. Concept

Local Open Compute extends TXTWRK Server One by providing additional resources for participation in a coordinated distributed computing network.

The enhanced product includes the capabilities of Server One and additional storage, processing and networking capacity.

Customers can operate their own services while optionally contributing agreed resources to the wider network.

7. Resource Allocation

The initial concept proposes 1 TB of dedicated Local Open Compute storage per participating device, separate from personal or business storage.

Resource	Initial Allocation	Purpose
Total dedicated network storage	1 TB	Distributed network participation
CDN-style cache	100 GB	Frequently requested content
Remaining storage	900 GB	Other approved network storage workloads
CPU	To be specified	Independent processing tasks
GPU	Model-dependent	Supported accelerated workloads
Bandwidth	Managed allocation	Network delivery and resource sharing

Allocations may change according to demand, contractual agreements and the resource limits accepted by participants.

Actual usable storage will be lower after operational overhead.

8. Network Architecture

TXTWRK proposes a hybrid infrastructure combining:

•Independently owned home servers.

•TXTWRK network coordination services.

•Partner cloud infrastructure.

•Traditional data centers.

•CDN providers.

•Regional storage and processing nodes.

The coordination system would allocate workloads according to location, availability, performance, security and cost.

The network should initially focus on workloads that do not require extremely low-latency communication between distributed machines.

9. Local Content Distribution

Popular files could be replicated across approved nodes in relevant geographic regions.

For example, a UK business could have suitable static assets cached on several participating servers serving different locations.

The network would need to account for:

•Content popularity and geographic demand.

•Node availability and upload capacity.

•Network routing and latency.

•Storage replication and consistency.

•Security and encryption.

•Bandwidth usage and partner agreements.

Residential nodes would complement conventional CDNs where measurements show an advantage.

Geographic proximity alone does not guarantee improved performance.

10. Distributed Compute

Potential workloads include:

•Independent CPU processing.

•Batch processing.

•AI inference requests.

•Selected GPU workloads.

•Media processing.

•Distributed storage and caching.

•Background application jobs.

Large-scale AI training may remain better suited to specialized data centers because of the high-speed communication requirements between GPUs.

TXTWRK should investigate compute workloads through research and controlled benchmarks before making performance commitments.

11. Bandwidth and Network Coordination

TXTWRK and participating partners would establish mutually agreed network policies.

These would govern:

•Resource allocation.

•Bandwidth commitments.

•Workload scheduling.

•Service quality.

•Node eligibility.

•Network monitoring.

•Security and compliance.

Participants should have clear visibility into resource commitments and the ability to manage participation within agreed terms.

12. Credits and Compensation

Participating owners could earn TXTWRK credits for verified resource contributions.

Mechanism	Proposed Approach
Storage contributions	Reward verified useful capacity and availability
Compute contributions	Reward successfully completed workloads
Bandwidth contributions	Reward approved data delivery
Compensation	TXTWRK credits
Redemption	Optional periodic cash settlement
Settlement frequency	Quarterly, six-monthly or another agreed interval

The commercial model must account for electricity, connectivity, operating costs, taxes, fraud prevention and service reliability.

No financial return is guaranteed.

13. Security

The network should use defense-in-depth security.

Proposed measures include:

•Secure boot and signed updates.

•Encrypted storage and network traffic.

•Authenticated node identities.

•Workload isolation.

•Remote attestation where supported.

•Tamper detection.

•Compromise monitoring.

•Automated quarantine and service migration.

A physical tamper event could generate a report to trusted infrastructure or nearby nodes, but this must not be treated as proof that a compromised device can reliably report its own condition.

14. Reliability and Failover

The network should tolerate individual devices going offline for maintenance, cooling, hardware failure or connectivity interruptions.

Potential techniques include:

•Replicated storage.

•Erasure coding.

•Redundant service execution.

•Health monitoring.

•Automated failover.

•Planned workload migration.

•Backup and recovery.

A node may temporarily stop operating while another eligible node handles its supported workload.

Availability guarantees will depend on redundancy and tested recovery procedures.

15. Hybrid Infrastructure

TXTWRK will initially depend on a combination of residential infrastructure and conventional providers.

Traditional data centers remain important for:

•Central coordination.

•High-bandwidth workloads.

•Critical services.

•Large GPU clusters.

•Disaster recovery.

•Regional connectivity.

Long-term research may investigate greater network independence, but independence is not required for the initial commercial model.

---

Part Three — Sustainability and Product Longevity

16. Long-Term Device Support

TXTWRK proposes a development culture based on durability rather than frequent hardware replacement.

New product editions may be introduced approximately every three to five years.

Older devices should remain compatible with supported network functions wherever feasible.

The ambition is to maintain useful participation for decades through updates, repairs and changing workload assignments.

17. Hardware Repurposing

Older nodes may transition to less demanding responsibilities.

Device Condition	Potential Role
New high-performance device	Advanced applications and compute
Mature device	General hosting and distributed storage
Older compatible device	Caching and lightweight processing
Limited-capacity device	Monitoring or other low-demand services
Unsupported or unsafe device	Retirement, refurbishment or recycling

A century-long service life is an aspiration for continuity and maintainability, not a guarantee that original components will operate indefinitely.

18. Buyback and Recycling

TXTWRK may develop a buyback program to support upgrades and responsible reuse.

Returned devices could be:

•Inspected and refurbished.

•Reassigned to educational projects.

•Redeployed for lighter workloads.

•Used for spare parts.

•Recycled when continued operation is no longer viable.

Energy consumption, repair costs and cybersecurity support must determine whether continued operation is practical.

---

Part Four — Research and Partnerships

19. Collaborative Development

TXTWRK intends to develop the initiative with industry specialists, technology partners, independent researchers and volunteers.

Research areas include:

•Server hardware and manufacturing.

•Networking and connectivity.

•Distributed storage.

•GPU and CPU scheduling.

•Cybersecurity.

•Energy efficiency.

•Application integration.

•Customer experience.

•Resource accounting.

Volunteer research should have clear expectations, appropriate recognition and genuine educational value. Commercial operational responsibilities require appropriate resourcing.

20. Partner Opportunities

Partner Category	Potential Contribution
Hardware manufacturers	Components and modular server designs
Hosting companies	Domain services and management tools
Network operators	Connectivity and routing expertise
Cloud providers	Hybrid compute and storage
CDN operators	Content delivery integration
Security companies	Device trust and threat protection
Universities	Research and independent testing
Software developers	Applications and platform integrations

These represent potential collaborations rather than confirmed partnerships.

---

Part Five — Network Capacity and Economics

21. Illustrative Storage Growth

Assuming each participating Local Open Compute server contributes 1 TB of raw dedicated storage:

Participating Servers	Raw Network Storage	CDN Cache Allocation
100	100 TB	10 TB
1,000	1 PB	100 TB
10,000	10 PB	1 PB
100,000	100 PB	10 PB
1,000,000	1 EB	100 PB

These figures are theoretical and exclude replication, redundancy, offline devices, metadata and operational reserves.

They are not customer acquisition or deployment forecasts.

22. Economic Requirements

The commercial feasibility model must evaluate:

•Hardware manufacturing costs.

•Product distribution and warranty costs.

•Electricity consumption.

•Residential internet limitations.

•Network coordination expenses.

•Customer support.

•Security operations.

•Partner revenue sharing.

•Resource compensation.

•Real customer demand.

Network participation must create sufficient value to justify its operating costs.

23. Principal Technical Challenges

Challenge	Research Response
Residential upload limitations	Benchmarking and workload selection
Dynamic IP addresses and NAT	Secure tunnels and connectivity services
Unreliable nodes	Redundancy and automated recovery
Hardware differences	Standardized compatibility profiles
Data security	Encryption and isolation
Network economics	Usage metering and resource accounting
Electricity costs	Energy-efficient scheduling
Long-term support	Modular design and compatibility policies
Legal compliance	Data protection and regulatory assessment

---

Part Six — Development Roadmap

24. Proposed Development Phases

Phase	Objective	Principal Deliverable
1	Product definition	User experience and hardware requirements
2	Standalone prototype	Working TXTWRK Server
3	Platform integration	TXTWRK account and partner connectivity
4	Distributed research	Small Local Open Compute test network
5	Pilot deployment	Reliability and performance measurements
6	Commercial validation	Manufacturing and economic assessment
7	Controlled expansion	Additional models and network growth

No fixed launch dates are established in this report.

25. Research Milestones

Before a wider launch, TXTWRK should demonstrate:

1. A working plug-and-play standalone server.
2. Reliable local hosting and management.
3. Secure TXTWRK platform integration.
4. A small distributed storage network.
5. Tested failover and node recovery.
6. Verified bandwidth and compute accounting.
7. Measurable energy and operating costs.
8. A commercially viable support and compensation model.

---

Part Seven — Industry Opportunity

26. Reusing Established Technologies Differently

TXTWRK is not claiming to invent distributed computing, edge hosting, failover or CDN technology.

The proposal is to combine established technologies into a more accessible, integrated product ecosystem.

The innovation opportunity lies in:

•Making home infrastructure approachable.

•Connecting owned servers to useful services.

•Enabling optional distributed participation.

•Creating an accessible partner ecosystem.

•Supporting long-term hardware use.

•Developing sustainable resource compensation.

•Making infrastructure education part of the product experience.

The objective is to revisit barriers that have historically limited adoption and test whether new hardware, software and network approaches can overcome them.

27. Supporting UK Startups

TXTWRK aims to make infrastructure ownership a practical option for UK entrepreneurs and community organizations.

The long-term ambition includes reaching a potential market of millions of new and existing businesses.

This represents a strategic aspiration rather than a verified market forecast.

28. Criteria for Success

TXTWRK should measure success through:

•Customer ease of use.

•Service reliability.

•Hardware longevity.

•Security.

•Economic sustainability.

•Partner participation.

•Network utilization.

•Environmental performance.

•Accessibility to small organizations.

The project should progress from working prototypes and measured evidence rather than assuming that theoretical capacity automatically produces commercial value.

---

Conclusion

TXTWRK Servers and TXTWRK Servers: Local Open Compute represent two interconnected initiatives.

Part One enables individuals, communities and businesses to operate their own digital infrastructure through accessible home server hardware and integrated software.

Part Two investigates how independently owned devices can contribute to a wider distributed computing network.

The network begins as a hybrid system, combining home infrastructure with established hosting, cloud and data center services.

Its long-term direction emphasizes sustainability, maintainability, local ownership and collaborative innovation.

The technical and commercial challenges are significant. Success will require partnerships, prototypes, research and measured validation.

TXTWRK's objective is to make digital infrastructure accessible today while developing a network capable of evolving for generations.

---

Founding Principle

> Build locally. Connect globally. Last for generations.

A server should not be defined only by the day it was manufactured, but by the value it can continue providing to the people and networks that depend on it.

---

Document Status: Initial Concept and Feasibility Report

Organization: TXTWRK

Website: https://txtwrk.com

Date: October 2026

Commercial Status: Proposed product concepts, indicative starting prices and research objectives. Specifications, performance, partnerships and release plans remain subject to validation.

Let’s work together @Meta & @XAI

TXTWRK.com | Home

Helping the world make text work in daily life...

@ImSunnyClaire
Sunny Claire • 17 Oct 2026 12:23

🚀 Keep up the great work https://txtwrk.com

TXTWRK.com | Home

Helping the world make text work in daily life...

txtwrk.com

Open Link ↗

COMMENT

FEATURE

GIFT

ASK AI

OPEN POST

COPY LINK

COPY EMBED CODE

COPY POST ID

SAVE

⛶

@TXTWRK
TXTWRK

🌎; All Activity; Announcement; Business; Challenges; Checklists; Community; Development; Getting started; Guides; History; Programming; Search; Support; Technology; Tools; Volunteer; Work; World
11:38 22/09/2026

Views: 79
Comments: 1

Documentation: Checklists: All Activity

Technology

Neutral

TXTWRK Checklists All Activity installed today, next to Search

TXTWRK has extended All Activity into Checklist technologies, adding another specialised surface to an activity system that already operates across the Homepage, Profiles, Maps and the API Kit. The importance of the checklist implementation is that activity is not being developed as an isolated audit log for another product feature. Instead, the existing TXTWRK activity architecture is adapted to structured work: users can move from discovering activity across the platform to understanding activity surrounding a particular checklist, and now an individual checklist item. This gives Checklist technologies both an operational purpose—managing work—and a historical purpose—understanding how that work actually progressed.

Core capabilities introduced

•Checklist-level All Activity: activity can be viewed directly inside the checklist experience while remaining restricted to the relevant enclosing post.

•Checklist-item filtering: users can select a particular checklist item and retrieve activity associated specifically with that item.

•Existing All Activity controls remain available: username, search, time, ordering, activity categories and applicable scope controls continue to provide additional ways of exploring the history.

All Activity surface	Context provided	What a user can learn
Homepage	Platform-wide discovery	What is happening across TXTWRK
Profile	Individual context	Activity surrounding a particular person
Maps	Geographic context	What is happening in a location
API Kit	Programmatic context	How activity can be consumed by integrations
Checklist	Structured-work context	How a checklist/post has progressed
Checklist Item	Individual work-item context	How a specific part of that checklist progressed

The Checklist Item filter is the key adaptation in this implementation. Checklist items are presented through a selector organised according to their existing checklist groups, making the activity interface reflect the structure of the work itself. Selecting an item changes the question being asked of All Activity from “what happened in this checklist?” to “what happened around this particular piece of work?” The selected item is combined with the enclosing post context, providing a progressively narrower history rather than relying on a simple keyword match. That gives TXTWRK a hierarchy of discovery running from platform activity through to highly specific work-item activity.

What the item-level adaptation enables

•Progress investigation: review the history surrounding one individual item instead of manually searching through the entire checklist timeline.

•Process learning: completed checklists can become historical records showing how particular stages of work developed, rather than becoming static completed task lists.

•Contextual investigation: item selection can work alongside other activity controls, allowing the history to be examined by participant, period, search term or other supported activity dimensions.

Level	Example question	Activity scope
Platform	What is happening across TXTWRK?	All Activity
Person	What has happened around this user?	Profile
Location	What has happened here?	Maps
Checklist	How did this body of work progress?	Post/checklist
Checklist item	How did this exact part of the work progress?	Post + selected item

This creates a broader knowledge and learning capability around checklists. A normal checklist is principally concerned with the present state of work: what exists, what is outstanding and what has been completed. All Activity adds the temporal layer. Users can look backwards through activity and understand the path that led to the current state. Item-level filtering makes that history substantially more useful on large or complex checklists because the user does not need to reconstruct an individual item's story from an entire project history. As TXTWRK accumulates activity, previous checklists can consequently provide useful evidence of how work was approached, where interaction occurred and how individual elements progressed.

Wider product benefits

•One activity concept across multiple technologies: users encounter All Activity across Homepage, Profiles, Maps, API Kit and now Checklist technologies instead of learning unrelated history systems.

•Granularity without fragmentation: the user can move from broad discovery to post/checklist history and then individual-item history while remaining within the same conceptual activity system.

•Reusable historical knowledge: checklist activity can provide more than an audit trail; it can help users revisit previous work and understand the progression behind completed outcomes.

The comparison with established work-management technology helps clarify where this approach differs. monday.com provides board activity and an Item Activity Log. Jira records activity against individual work items, including areas such as comments, history and work logs. ClickUp provides individual task activity alongside broader Activity views. These products demonstrate the value of detailed work history. The distinguishing aspect of TXTWRK's implementation is not simply that checklist items have history, but that checklist-item activity becomes another specialised view of an activity concept already spanning people, geographic discovery, platform discovery and API consumption.

Capability	TXTWRK	monday.com	Jira	ClickUp
Broad activity experience	Homepage All Activity	Board Activity Log	Primarily work-item/project activity	Activity View
Individual work-item history	Checklist Item All Activity	Item/Subitem Activity	Work-item Activity	Task Activity
Person-oriented activity context	Profiles	Person filtering	User/change information within work items	Person/activity filtering
Geographic activity context	Maps	Not a central Activity Log context	Not a central work-item Activity context	Not a central Activity View context
Programmatic activity context	API Kit	APIs available	APIs available	APIs available
Structured checklist context	Yes	Items/subitems	Work items/subtasks	Tasks/checklists
Specific checklist-item filtering	Yes	Item-level activity	Work-item level	Task/checklist activity
Broad-to-specific activity model	Platform → Profile/Map → Checklist → Checklist Item	Board → Item/Subitem	Project → Work item	Location → Task
TXTWRK distinction	One All Activity concept adapted across multiple platform technologies	Strong board/item history	Strong issue/work history	Strong task/workspace activity

There is also an important architectural distinction as Checklist technologies develop further. TXTWRK starts from the concept that All Activity can operate across several platform surfaces, with each technology adapting activity according to its own context. Checklist activity therefore does not have to end with recording that a task changed. It can participate in the wider discovery model used by Homepage activity, a person's Profile activity, geographically relevant activity through Maps and programmatic use through the API Kit. Adding the Checklist Item filter makes this adaptation considerably more specific: users can retain the wider All Activity capabilities while drilling down to one defined component of a checklist. The result is a checklist technology that can organise work, expose how that work progressed, and allow people to return later and learn from the history of individual items as well as the checklist as a whole.

1/6

🗖 VIEW

@ImSunnyClaire
Sunny Claire • 25 Sep 2026 20:29

It’s an awesome feature

COMMENT

FEATURE

GIFT

ASK AI

OPEN POST

COPY LINK

COPY EMBED CODE

COPY POST ID

SAVE

⛶

@TXTWRK
TXTWRK

🌎; AI; Announcement; Apps; Assets; Business; Challenges; Community; Data; Development; History; In 1000 years; Interesting Knowledge; Investors; Language; Leaders; Learning; Lifestyle; Politics; Safeguarding; Support; Technology; Transparency; Views; Work; World
17:31 20/09/2026

Views: 31

Documentation: Progress: In 1000 years

Technology

Neutral

The reason why we outsmart big tech such as Facebook, TikTok, etc

We're not in it for the short term gains, we are in it for the long term gains. Continue listening...

We can survive for the next 1000 years at very small scale, that's the magic in our development, alongside being underpinned by our founder's existing other ventures that propel the network.

COMMENT

FEATURE

GIFT

ASK AI

OPEN POST

COPY LINK

COPY EMBED CODE

COPY POST ID

SAVE

⛶

@TXTWRK
TXTWRK

🌎; Announcement; Apps; Business; Careers; Challenges; Checklists; Community; Creativity; Data; Development; Getting started; History; Lifestyle; Live; Messaging; News; Posts; Programming; Stories; Support; Technology; Tools; Work; World
19:21 15/09/2026
02:22 16/09/2026 📷
Views: 68

Documentation: Live: Audio Rooms

Technology

Neutral

TXTWRK Development Report

Audio Across Posts, Checklists & Messaging

16 September 2026

Today marked a significant expansion of audio communication across TXTWRK.

What began as Audio Rooms connected to posts has now developed into audio functionality spanning three major areas of the network:

1. Posts — Audio Rooms
2. Checklists — Audio Rooms
3. Messaging — Audio Chats

Rather than creating one generic audio feature and forcing it into every part of TXTWRK, each implementation has been designed around the permissions, storage requirements and user behaviour of the area in which it operates.

The result is the beginning of a network-wide audio communication layer across TXTWRK.

---

1. Audio Rooms in Posts

The first implementation provides Audio Rooms attached directly to TXTWRK posts.

A post can contain its own Audio Room, allowing the post itself to become the centre of a recorded audio discussion.

Room Status

A newly created Audio Room begins Offline.

The room owner can switch it between:

•Offline

•Live

The visual state of the room changes accordingly, providing an immediate indication of whether the host is currently accepting participation.

The room owner controls when the room becomes active rather than simply leaving recording permanently available.

Guest Participation

Visitors can request to join an Audio Room.

The room owner receives a participation log and can manage requests by:

•Accepting a participant

•Removing acceptance

•Blocking a participant

•Viewing all requests

•Viewing blocked users

•Unblocking users

Accepted participants are then permitted to record within the room.

This creates a moderated audio environment rather than allowing unrestricted recording against a public post.

Recording Limits

The host has unrestricted recording time.

Guest recording limits can be configured using options including:

•10 seconds

•15 seconds

•30 seconds

•1 minute

•3 minutes

•Unlimited

This allows the room owner to determine the expected style of participation.

A room could therefore be configured for very short voice responses or longer-form discussion.

Dynamic Room Behaviour

While an Audio Room is Live, its state and participation information can refresh dynamically.

Guests can discover when they have been accepted without needing to manually reload the entire page.

Once accepted, recording functionality becomes available to them.

Recording and Playback

Audio recordings are stored against the Audio Room and can subsequently be played through the room interface.

Playback and pagination allow a growing Audio Room to remain usable as additional recordings are added.

Data Accounting

TXTWRK-hosted recordings participate in TXTWRK's data accounting system.

This connects Audio Rooms to the wider storage/data model rather than treating audio as unlimited external media.

Post Audio Room Structure

Conceptually:

Post
└── Audio Room
├── Offline / Live
├── Host
├── Join Requests
├── Accept / Block
├── Guest Recording Limits
├── Recordings
└── Playback

The important distinction is that the audio conversation belongs to the post itself.

Users do not have to leave the post and create a separate group conversation simply to discuss it using audio.

---

2. Audio Rooms in Checklists

The second major development was adapting Audio Rooms for TXTWRK Checklists.

This required a different architecture because a checklist is not a social post.

It represents structured work, collaboration and existing permissions.

For this reason, Checklist Audio Rooms were developed as their own system rather than simply reusing the Post Audio Room participation model.

Audio Attached to a Checklist Item

A Checklist Audio Room belongs directly to a checklist item.

Conceptually:

Checklist
└── Checklist Item
└── Audio Room

This allows an audio discussion to remain attached to the exact piece of work being discussed.

Instead of discussing a checklist task somewhere else in a general messaging conversation, the discussion remains with the task.

Turning Audio On

Checklist items can expose an Audio Room control allowing the feature to be enabled for that particular item.

This means Audio Rooms do not need to exist unnecessarily on every checklist item.

They can be activated where audio collaboration is useful.

Checklist Permissions

Unlike public Post Audio Rooms, checklist participants already operate within a permissions system.

Therefore the Post Audio Room workflow of:

Join
↓
Request
↓
Host Accepts
↓
Recording Enabled

is unnecessary.

Instead:

Checklist Permission
↓
Audio Room Permission

Users who already have the appropriate checklist permissions can participate automatically.

This makes the Checklist Audio Room behave as part of the collaborative work environment rather than as a separate social room.

Recording Topics

Checklist recordings can optionally be associated with topics.

This provides another organisational layer for Audio Rooms that may accumulate substantial discussion.

Recordings can subsequently be filtered according to the selected topic.

This is particularly useful when one checklist item contains several areas of discussion.

Date Organisation

Recordings can be grouped and retrieved by date.

Features such as:

•Play Today

•Date grouping

•Initial recording limits

•View More loading

allow longer-running checklist discussions to remain manageable.

Live Behaviour

Checklist Audio Rooms can still operate with Live behaviour.

Polling can be limited to situations where:

•the Audio Room is Live; and

•the room is currently within the user's viewport.

This avoids unnecessary background requests while retaining responsive behaviour when users are actively viewing the room.

---

3. Checklist Audio Storage

Checklist Audio Rooms introduced another important capability: selectable storage.

When configuring the Audio Room, storage can be directed to either:

1. TXTWRK
2. The user's connected server through the Directory API infrastructure

TXTWRK Storage

TXTWRK can host the audio using the user's available TXTWRK data balance.

Connected Server Storage

Where the user has configured suitable server infrastructure through TXTWRK's Directory API system, the audio object can instead be stored on that server.

Conceptually:

Checklist Recording
│
▼
TXTWRK
│
├────────► TXTWRK Data Balance
│
└────────► Connected Directory API Server

TXTWRK can therefore remain responsible for the checklist, Audio Room, recording metadata and interface without necessarily being responsible for permanently storing the underlying media object.

This begins separating two concepts:

the network managing the collaboration

from:

the infrastructure storing the media

---

4. Public Checklist Listening

Checklist Audio Rooms were also designed to support public listening where appropriate.

This means an Audio Room can potentially be heard by people who are not authenticated TXTWRK participants while recording permissions remain protected.

The distinction becomes:

Listening
│
└── Can be public where enabled

Recording
│
└── Requires appropriate checklist access

This allows checklist owners to expose useful audio information without granting public users the ability to contribute recordings.

---

5. Audio Chats in Messaging

The third major development brought recorded audio into TXTWRK Messaging.

Audio Chats are being integrated into both:

•Direct conversations

•Group conversations

Unlike Post and Checklist Audio Rooms, Messaging Audio is designed around private asynchronous communication.

It therefore behaves more like a conventional voice message while still making use of TXTWRK's wider infrastructure model.

Messaging Composer

The existing messaging composer gains a microphone control positioned alongside the existing attachment controls.

Conceptually:

🎙️ 🔗 Message... Send

Users can record an Audio Chat directly from the messaging interface.

Recording

Browser recording uses the available media recording capabilities of the user's device/browser.

Once recording begins, the user can stop the recording and preview the pending audio before sending it.

Audio Without Text

An important part of the implementation is that an Audio Chat does not require a text message.

A message can therefore consist entirely of:

🎙️ Audio Recording

rather than requiring:

Text + Audio Recording

This allows audio to behave as a genuine messaging format rather than merely as an attachment to text.

Direct Conversations

Audio can be recorded and sent inside ordinary one-to-one TXTWRK conversations.

Group Conversations

The same capability is available within group messaging.

The messaging architecture therefore becomes:

Messaging
│
├── Direct Chat
│ └── Audio Chat
│
└── Group Chat
└── Audio Chat

---

6. Messaging Audio Storage

Messaging Audio Chats also introduce selectable storage.

The default storage destination is TXTWRK Data Balance.

A user with an appropriate Messaging API/server connection can instead choose to store Audio Chats on their connected server.

Default

Audio Storage:
TXTWRK Data Balance

This requires no additional server configuration.

Connected Server

Where suitable infrastructure has been configured:

Audio Storage:
My Messaging API Server

can be selected instead.

Conceptually:

Audio Chat
│
▼
TXTWRK
│
├────────► TXTWRK Data Balance
│
└────────► Messaging API / User Server

This allows users who operate their own infrastructure to preserve their TXTWRK data allowance by storing the underlying recording themselves.

---

7. TXTWRK Messaging Audio Storage Structure

TXTWRK-hosted Messaging Audio has been deliberately separated from the earlier Audio Room systems.

Its storage hierarchy is:

/1-audio-rooms-messaging/
{memberID}/
direct/
{chat_controller_id}/
audio_xxxxx.webm

group/
{group_id}/
audio_xxxxx.webm

This keeps:

•Post Audio Rooms

•Checklist Audio Rooms

•Messaging Audio Chats

separate at the storage level.

The implementations therefore do not need to interfere with one another simply because they all contain recorded audio.

---

8. Messaging Audio Data Accounting

When an Audio Chat is stored by TXTWRK, it consumes the appropriate user's TXTWRK data balance.

The recording therefore becomes part of the same broader storage economy as other TXTWRK-hosted data.

Where the user's own Messaging API server is selected instead, TXTWRK does not need to charge its own storage balance for the underlying audio object.

This creates a practical reason for users with their own infrastructure to connect it.

---

9. Audio Deletion and Ownership

Messaging storage also requires different deletion behaviour depending on where the media lives.

TXTWRK-Hosted Audio

Where TXTWRK owns the physical stored object, the system can manage:

•physical deletion;

•storage metadata;

•data accounting; and

•appropriate data refunds.

User-Server Audio

Where the audio resides on a user's connected server, TXTWRK should not treat that physical object as its own property.

Removing or hiding the TXTWRK message therefore does not mean TXTWRK should reach into the user's server and destroy the original media object.

Conceptually:

TXTWRK-hosted recording
↓
TXTWRK controls storage lifecycle

User-server recording
↓
Server owner controls storage lifecycle

This establishes a clearer ownership boundary between TXTWRK and connected infrastructure.

---

10. Protecting Private Messaging Audio

The TXTWRK Messaging Audio storage directory has also been treated separately from the earlier public Audio Room work.

The directory:

/1-audio-rooms-messaging/

can have its own .htaccess protection.

The protection includes:

•directory indexing disabled;

•executable scripts blocked;

•unexpected file types blocked;

•MIME sniffing protection;

•direct/no-referrer requests rejected; and

•playback requests restricted to TXTWRK-originating pages under the current hotlink-protection model.

This protection applies only to Messaging Audio.

The earlier Post and Checklist Audio Room directories are not changed by this Messaging-specific protection.

---

11. End-of-Day Audio Architecture

At the end of today's work, TXTWRK effectively has three different audio systems serving three different purposes.

Area	Audio Type	Primary Purpose	Participation	Storage
Posts	Audio Rooms	Social discussion	Host + requested/accepted guests	TXTWRK
Checklists	Audio Rooms	Work collaboration	Checklist-authorized users	TXTWRK or connected server
Messaging	Audio Chats	Private communication	Direct/group participants	TXTWRK or Messaging API server

This separation is important.

The goal has not been to create three copies of the same microphone feature.

Each implementation reflects its environment.

---

12. Social Audio

Post Audio Rooms represent the social layer.

SOCIAL
│
▼
Post
│
▼
Audio Room
│
├── Host
├── Live / Offline
├── Join Requests
├── Accept / Block
├── Recording Limits
└── Playback

The conversation revolves around published content.

---

13. Work Audio

Checklist Audio Rooms represent the work layer.

WORK
│
▼
Checklist
│
▼
Checklist Item
│
▼
Audio Room
│
├── Checklist Permissions
├── Recording
├── Topics
├── Date Organisation
├── Public Listening
└── Selectable Storage

The conversation revolves around a specific piece of work.

---

14. Private Audio

Messaging Audio Chats represent the private communication layer.

PRIVATE
│
▼
Messaging
│
├── Direct
│ └── Audio Chat
│
└── Group
└── Audio Chat

The conversation revolves around private communication between users or groups.

---

15. One Audio Layer Across TXTWRK

Together, the three implementations can be viewed as:

TXTWRK AUDIO
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
SOCIAL WORK PRIVATE
│ │ │
POST CHECKLIST MESSAGING
│ │ │
AUDIO ROOM AUDIO ROOM AUDIO CHAT
│ │ │
Discussion Collaboration Conversation

This is a much broader development than simply adding voice messages.

Audio now has a place across three fundamentally different types of activity on TXTWRK.

---

16. Competitive Comparison — TXTWRK Audio Across the Network

Recorded audio itself is not unusual among modern communication networks.

Major messaging and collaboration platforms already provide various forms of:

•voice messages;

•recorded clips;

•voice channels;

•calls;

•meetings; and

•synchronous audio.

The more relevant comparison is therefore not:

"Does TXTWRK have audio?"

The more useful question is:

"Where can audio exist within TXTWRK, what is it attached to, who controls participation, and who controls its storage?"

That produces a considerably more interesting comparison.

---

17. Comparison With Other Major Networks

Capability	TXTWRK	WhatsApp	Discord	Signal	Slack	Microsoft Teams
Recorded audio in direct messaging	Yes	Yes	Yes	Yes	Yes	Yes
Recorded audio in group messaging	Yes	Yes	Yes	Yes	Yes	Yes
Audio connected directly to social posts	Yes	No direct equivalent	Different model	No	Different model	Different model
Dedicated Audio Room attached to a post	Yes	No	Voice channels use a different model	No	Huddles use a different model	Meetings use a different model
Audio attached directly to checklist/work items	Yes	No	No direct equivalent	No	No direct equivalent	No direct equivalent
Existing checklist permissions control recording access	Yes	—	—	—	—	—
Public listening with controlled recording participation	Yes	—	Different model	—	Different model	Different model
Choice between platform storage and user's own server	Yes	No normal user-facing equivalent	No normal user-facing equivalent	No normal user-facing equivalent	No normal user-facing equivalent	No normal user-facing equivalent
Own-server audio can avoid platform data usage	Yes	—	—	—	—	—
Audio integrated across social + work + private messaging	Yes	Primarily messaging	Community + messaging	Primarily messaging	Work + messaging	Work + messaging

The comparison is not intended to suggest that other platforms lack sophisticated audio systems.

Several of them have extremely mature audio, calling, transcription, encryption and mobile experiences.

The distinction is the combination TXTWRK is developing.

---

18. Comparison With Messaging Networks

Platforms such as WhatsApp and Signal demonstrate the established value of asynchronous voice communication.

Voice recordings work naturally when users want to communicate something faster or more personally than typing a message.

TXTWRK Messaging now enters that same general category through Audio Chats.

However, TXTWRK's implementation also connects messaging audio to its wider infrastructure model.

A user can potentially choose between:

TXTWRK-hosted media

or:

User-hosted media

while continuing to use the same TXTWRK conversation.

The communication network and storage provider therefore do not necessarily have to be the same entity.

---

19. Comparison With Community Platforms

Discord demonstrates another model where audio extends beyond conventional private messaging.

Its ecosystem combines messaging with community-oriented voice functionality.

TXTWRK Post Audio Rooms approach community audio differently.

Instead of creating a voice channel that exists independently of a piece of content, the Audio Room belongs directly to a post.

Conceptually:

Traditional Community Voice

Community
↓
Voice Channel
↓
Conversation

TXTWRK Post Audio

Post
↓
Audio Room
↓
Conversation about that Post

The content itself becomes the location of the audio discussion.

---

20. Comparison With Workplace Platforms

Slack and Microsoft Teams demonstrate how recorded communication can become useful in professional collaboration.

Audio and video clips can reduce the need for synchronous meetings and allow information to be consumed asynchronously.

TXTWRK Checklist Audio Rooms approach the work context from the perspective of the work item itself.

Instead of:

Channel
↓
Discussion
↓
User determines which task it concerns

TXTWRK can provide:

Checklist Item
↓
Audio Discussion
↓
Context already established

The recording is already attached to the object being discussed.

This reduces the separation between communication and the work itself.

---

21. Storage as an Architectural Difference

One of the most significant differences introduced during today's development is the ability to separate TXTWRK's application layer from the physical storage layer.

A conventional hosted network can broadly be represented as:

User
│
▼
Platform
│
▼
Platform-Controlled Storage

TXTWRK is developing another possibility:

User
│
▼
TXTWRK
│
├────────────► TXTWRK Storage
│
└────────────► User-Controlled Server

TXTWRK can remain responsible for:

•identity;

•permissions;

•conversations;

•checklist relationships;

•room metadata;

•interfaces; and

•application logic

while the physical media can, where supported, live somewhere selected by the user.

---

22. Data Balance or Infrastructure Ownership

This creates two different ways of consuming an audio service.

TXTWRK Data Balance

The simplest route is:

Record
↓
TXTWRK
↓
TXTWRK Storage
↓
Data Balance

No external infrastructure is required.

User Infrastructure

A user with their own compatible server can instead use:

Record
↓
TXTWRK
↓
Connected Server
↓
User-Controlled Storage

This can reduce consumption of the user's TXTWRK data balance while giving the server owner greater control over the underlying media object.

---

23. The Network and the Storage Do Not Have to Be the Same Thing

This is an important architectural principle emerging from the work.

Historically, users of a hosted social or messaging network generally expect:

Platform = Application + Communication + Storage

TXTWRK can increasingly operate as:

TXTWRK = Application + Communication + Coordination

while:

Storage = TXTWRK OR User Infrastructure

That distinction is now visible in both:

•Checklist Audio Rooms

•Messaging Audio Chats

and can potentially become relevant to additional TXTWRK services in the future.

---

24. Different Permission Models for Different Contexts

Another important outcome is that TXTWRK has not attempted to impose one permission model everywhere.

Post

A public/social Audio Room requires explicit moderation.

Visitor
↓
Join
↓
Host Accepts
↓
Record

Checklist

A collaborative work environment already knows who should have access.

Checklist User
↓
Existing Permission
↓
Record

Messaging

A private conversation already establishes participation.

Conversation Member
↓
Direct / Group Access
↓
Record and Send

These are three different solutions because they solve three different problems.

---

25. Why This Is More Than a Microphone Button

From the user's perspective, all three systems may contain a microphone.

Technically and architecturally, however, today's work encompasses much more.

It includes:

•room ownership;

•Live/Offline state;

•participation requests;

•acceptance;

•blocking;

•recording limits;

•checklist permissions;

•public listening;

•recording topics;

•filtering;

•date organisation;

•direct messaging;

•group messaging;

•audio-only messages;

•inline playback;

•TXTWRK storage;

•connected-server storage;

•data accounting;

•storage ownership;

•deletion behaviour; and

•protected private media directories.

The microphone is therefore only the visible entry point into a much larger system.

---

26. TXTWRK's Emerging Audio Model

The architecture can now be summarised as:

┌─────────────────────────────────────────────┐
│ TXTWRK AUDIO │
└─────────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
SOCIAL WORK PRIVATE
│ │ │
▼ ▼ ▼
POSTS CHECKLISTS MESSAGING
│ │ │
▼ ▼ ▼
AUDIO ROOMS AUDIO ROOMS AUDIO CHATS
│ │ │
├───────┬───────┴───────┬───────┤
│ │ │ │
▼ ▼ ▼ ▼
RECORD PLAYBACK TXTWRK OWN SERVER
STORAGE STORAGE

This creates a foundation that can be extended rather than requiring an entirely new audio architecture every time another part of TXTWRK needs recorded communication.

---

27. Areas Where Established Platforms Remain More Mature

A competitive comparison should also recognise where long-established communication platforms have mature capabilities that TXTWRK can continue developing.

Depending on the platform, these include areas such as:

•native mobile recording experiences;

•end-to-end encrypted media delivery;

•transcription;

•captions;

•accessibility;

•noise processing;

•waveform interfaces;

•playback-speed controls;

•large-scale media delivery;

•synchronous calling;

•large voice channels;

•sophisticated notification systems; and

•extensive moderation infrastructure.

The significance of today's TXTWRK development is therefore not a claim that every individual audio capability exceeds those of established networks.

The significance is the combination and integration being developed.

---

28. TXTWRK's Combination

TXTWRK can increasingly be described as combining:

SOCIAL PUBLISHING

That combination is considerably more meaningful than treating Audio Rooms and Audio Chats as isolated features.

---

29. Today's Progress

At the beginning of this development path, Audio Rooms were associated primarily with posts.

The architecture now covers:

POSTS
│
▼
AUDIO ROOMS

CHECKLISTS
│
▼
AUDIO ROOMS

MESSAGING
│
▼
AUDIO CHATS

Each serves a different type of communication.

Posts provide social discussion.

Checklists provide work-related collaboration.

Messaging provides private conversation.

---

30. End-of-Day Position — 16 September 2026

By the end of today's work, recorded audio has moved from being a feature within one area of TXTWRK toward becoming a capability of the wider network.

The architecture now supports the idea that audio can belong to:

•published content;

•a collaborative task;

•a direct conversation; or

•a group conversation.

At the same time, the infrastructure work introduces the principle that the media itself can potentially belong either to:

•TXTWRK storage; or

•infrastructure controlled by the user.

That gives TXTWRK an increasingly clear separation between communication, context and storage.

The day's work can therefore be summarised simply:

> Posts gained conversation through Audio Rooms.
>
> Checklists gained contextual collaboration through Audio Rooms.
>
> Messaging gained private recorded communication through Audio Chats.
>
> And TXTWRK's audio architecture began moving beyond platform-only storage toward user-selectable infrastructure.

Not a bad day's work.

1/3

🗖 VIEW

COMMENT

FEATURE

GIFT

ASK AI

OPEN POST

COPY LINK

COPY EMBED CODE

COPY POST ID

SAVE

⛶

@TXTWRK
TXTWRK

🌎; America; Announcement; Business; Challenges; Community; Creativity; Data; Development; Feedback Views; History; In 1000 years; Interesting Knowledge; Leaders; Learning; Lifestyle; News; Posts; Programming; Questions; Support; Technology; Transparency; Work; World
12:55 13/09/2026

Views: 123
Link Clicks: 2

Documentation: Data: Cross Network Data API

Technology

Neutral

🚀 TXTWRK LEGACY DATA FOREVER — Building Our Own Wayback Layer + Open Invitation to the Wayback Machine and 10 Key Networks

We’re making it.

Right now, inside TXTWRK Server & Workspace technologies and our open-source public working checklists, we’re building a pure web-code snapshot system — a lightweight, client-side Wayback-style tool.

No heavy files required.
Just clean HTML snapshots.
External images, CSS and scripts keep linking to the live originals.
Placeholders appear when something is gone.
Everything stays visible, discussable and improvable in public checklists where anyone can see the code and talk about it.

This is not a side project.
It is the next practical step in our long-term digital legacy mission.

TXTWRK already turns profiles into living records.
Checklists into public work containers.
Servers and Workspaces into real collaborative execution.

Now we are adding the ability to freeze the exact state of a page — whether it’s a community feedback post, a local checklist, a business pitch, or an external page that matters to the work — so the proof and the memory stay intact.

The Legacy Data Forever API Kit

We are designing an installable kit for networks that care about durable public memory.

It will let platforms:

•Expose structured, timestamped page snapshots

•Preserve public work records (profiles, checklists, feedback, contributions) in a consistent, interoperable format

•Keep external links and assets live where possible, with graceful placeholders where they are not

•Give communities ownership and visibility of their own legacy data

•Turn long-term digital memory into a shared layer instead of isolated silos

First real candidate: the Wayback Machine

The Wayback Machine (Internet Archive) is our first real candidate.

We would like to support them in research and explore integration of the Legacy Data Forever API Kit.

They have spent decades doing the essential work of preserving the web for everyone. We respect that work deeply and see a clear opportunity for complementary collaboration — not competition.

10 networks we should prioritise next

Our history on these networks must be maintained into a future where we can afford to keep human historical network data from profiles alive.

These are the platforms where millions of people have already built their public records, creative work, code, news contributions and music.

Losing that history would mean losing part of the human story.

YouTube & social media networks

1. YouTube
2. X (Twitter)
3. Facebook / Meta
4. Instagram
5. TikTok

Code-based & test networks

6. GitHub
7. Stack Overflow

News portals

8. BBC News
9. The Guardian

Music apps

10. SoundCloud (and platforms like Spotify / Bandcamp)

These networks hold the profiles, posts, videos, code, articles and music that form the living history of communities, creators, developers and citizens.

The Legacy Data Forever API Kit is designed so that this human network data can remain accessible, structured and protected long into the future — not locked behind changing company policies or disappearing pages.

We are developing the core capture and viewer openly in TXTWRK checklists — code visible, conversation public, contributions welcome.

Server directories and Workspace tools already give us the place to store, edit, test and iterate.

If the Wayback Machine or any of the networks listed above want to explore research collaboration or integration, the invitation is open today.

Let’s make long-term digital legacy something networks can install, share and protect together — forever.

Apply to the open checklist.
See the code.
Talk about it.
Help shape the Legacy Data Forever API Kit.

This is how text works for the next 100 years.

#TXTWRK #LegacyDataForever #WaybackMachine #OpenSourceWorking #DigitalLegacy

🗖 VIEW

Do you think your posts are online forever?

Select up to 1
0 people have voted

Yes

0 votes

Not sure

0 votes

Cast Vote

COMMENT

FEATURE

GIFT

ASK AI

OPEN POST

COPY LINK

COPY EMBED CODE

COPY POST ID

SAVE

Get back into TXTWRK...

TXTWRK

Filter Options

Post Filter Options

REELS

Incoming Claims (Cash Sales)

Log Book Purchases / Owned Records

Pending / Listed Log Book Sales

All Purchases

Sales Made (Sold Items)

Your Data

Forever Data Preservation

Core Features & Policy

Storage & Cost Overview

Why TXTWRK Matters

Partner Network Alliance Integration

Request Network Integration

Select Your Network

Legacy Forever API Kit (kit.php)

Settings Widget Code

Your Network Requests

Partner Network Status

Review Network Requests

Connect Your Server

1. Download TXTWRK.php

Messaging Requests

Your Connected Servers

Domains where you can create workspaces

Create Workspace

Coins Overview

Buy Coins

Withdraw Funds

Transaction History

Donations Overview

Incoming Donations

Outgoing Donations

Investor Overview

Investments Developed

Investments Purchased

Payee Details

People to Pay

Business Overview

Business Details

Funding & Product Details

Business Opportunities

Create Opportunity

Opportunity Money Details

My Opportunities

Business Opportunities Profile Module

Business Applications

Apply for Opportunity

Business Applications Made

Questionnaires

Create Questionnaire

Available Questions

Selected Questions

My Questionnaires

Questionnaire Profile Module

Search Organisations

Selected Organisations

My Organisations

My Addresses

Place Type

Photo / GIF

Phone Numbers

Emails

Links

Recurrence Type

Years (select multiple)

Recurring Months (1-12)

Recurring Day Names (1=Mon ... 7=Sun)

Exclusions

Link Profiles

Hosting Space (optional)

Set Cover Message

TXTWRK | QUICK LINKS

TXTWRK | ADMIN

Advertising

Ad Credits Overview

Buy Ad Credits