TXTWRK


PERSONAL
LinkingLinking
FollowingFollowing
ConnectionsConnections
MessagesMessages
NotificationsNotifications
Work
PostingPost
NotesNotes
NeedsNeeds
ContributionsContributions
TimetableTimetable
IntelIntel
To DosTo Dos
ChecklistsChecklists
SavesSaves
ScrapboardScrapboard
LinksLinks
DISCOVER
SearchSearch
ReelsReels
All ActivityAll Activity
CalendarCalendar
MapMaps
Getting StartedLaunch
HappeningHappening
Local PulseLocal Pulse
Products NearbyNearby
Trending TopicsTrending
TXTWRK PremiumPremium
Monetisation
CoinsCoins
AdvertisingAdvertising
SubscriptionSubscription
DonationDonation
Log BookLog Book
Organisation
BusinessBusiness
AddressesAddresses
InvestorInvestor
FinancialsFinancials
Quarterly'sQuarterly's
SharesShares
Server
ServerServer
WorkspaceWorkspace
Code PlaygroundPlayground
Learn More
AboutAbout
AIDAID
DataData
DevDev
Web ImpressionsImpressions
ToolsTools
EducationEducation
SafetySafety
ReaderReader
My Content
Login
Profile Image
Post submitted
Favorited by... X
Link Clicks X
All comments... X
More | 1/34

TXTWRK Verified Website

@TXTWRK

City of Derby, Derby, Derbyshire, East Midlands, England, United Kingdom, Europe

Our mission is to help people make text work in daily life. Get investment, volunteers, donations & more publicly…

Join the journey & make a profile to remember... Discover our investment opportunities via our card: @TXTWRK

We developed & support the @UnitedKingdom movement through #UnitedKingdom





Brand
12/01/2024
Learn more about me 𓇻
Donations: £2.50
▦ Photos
▦ Videos
▦ Covers
Applications
Questionnaires
Active: 27 minutes ago
Safety


OPENING TIMES
Show Images
Select a Store Location...
▼

Initializing schedule...

LOCAL PULSE

Profile Signals

Loading…
Loading profile signal…

Loading latest public Local Pulse signal…

Financials Financials
Quarterlys Quarterlys
Shares Shares
Notes Notes
Needs Needs
Contributions Contributions
Timetable Timetable
Intel Intel
To Dos To Dos
Notes Reel



Happening & Service
Happening Now and service updates connected to this profile


Happening in Offers
Offers available from this profile
Loading offers…






Connections
These are pages I added




Intel Pinned

Transparency of Operations
To make things even clearer, we are going to be updating our business registration in the coming days to 'TXTWRK Limited' in the UK & currently operate online in our startup phase, with workshops in educational institutions & community settings. We operate via the following domains: We monitise via the following sites: We operate the following social media: We operate the email addresses:
•Team@TXTWRK.com
•Support@TXTWRK.com
•Business@TXTWRK.com
•CommunityLibrary@TXTWRK.com
•Sponsors@TXTWRK.com
•Volunteer@TXTWRK.com
•Work@TXTWRK.com
•Writers@TXTRK.com
We operate the following TXTWRK pages: We operate the phone numbers: •447984582170 •0800 line coming soon We operate the following addresses:
•Currently in the process of setting up our office
•PO BOX coming soon & we focus on written communications
More intel:
•Need to request a removal from our Community Library, then simply email CommunityLibrary@TXTWRK.com
•Looking for account control, refer to ⚙ Settings/Linking to update your details or view https://txtwrk.com/account to understand your data or delete account
•We will never ask for your password or sensitive information and you should follow forms such as https://txtwrk.com/reset if you need to regain access to your account.
•We operate PayPal via our websites & also on TXTWRK
We keep this information up to date and concurrently here at TXTWRK via our intel reels - Last updated: 13/04/2026 00:16
Pinned Intel · 2026-04-12 23:14:46






Loading media...
1S HOLD OPEN
+AI
+Analysis
•TXTWRK
+Assets
+Media
•Logos
+Standards
•Font
+Audio
•From Our Community
+Podcasts
+AI
•Insider Preview
+Language
•S1 E1 Psychology Research by @ImSunnyClaire
+Challenges
•Web Development
+Checklists
+Dev
•Business
•Server
•Web
•For Community
+Community Mentions
•Recognised as Stories
+Datasets
+Measurements
•Daily Common
+Documentation
•3D, AR & VR
+AI
•Checklists with AI
•Future Capabilities
•Insights
•Make Artistic Web Impressions
+Models
•Apple Intelligence
•Bing Copilot
•ChatGPT
•Claude
•IBM WatsonX
•Perchance
•Qwen
•TXTWRK AID
•Teaching
+Accessibility
•Feature Displayer
+Account Management
•Switch Accounts
•All Activity
+Assets
•Feedback
•Learn how to use assets
+Posting
•Set Projection
+Business
•Opportunities
+Checklists
•All Activity
•Applying
•Checklists Command Input 1.0
•Create
•Create Checklist with AI
•Directory API
•Engage
•Public Working
•Replicate
+Templates
•Starter Set
•Connect
+Data
•Account
•Cross Network Data API
•Directory
•Donations
+Feedback
•Streets
•TXTWRK Pulse
+Feeds
•Just For You
•Following
+Games
•Quiz
•Happening
+History
•In 1000 years
+Investors
+Crowdfunding
•Kickstarter
+Funding Rounds
•Funding Round 1
•Funding Round 2
•Funding Round 3
+Summary of Funding Rounds
•3 Core Funding Rounds
•Tools
+Labels
•Introduction
+Live
•Audio Rooms
+Location
•Addresses
+Management
•Future Proof
+Media
•3D Elements
•Record Audio
+Web Impressions
•Stickers
•Themes & Slideshows
•Messaging
•Monitisation
•Notifications
+Posting
•Prize Draws
•Transparency
+Progress
•Friday Weekly Updates
•In 1000 years
•TXTWRK Team
•Questions
•Reels
•Registration
+Safeguarding
•Covers of Education
•Logical Filters
•Our Safety Tools
•Search
+Selling
•Log Book & Types
+Server
•Connect to TXTWRK
•TXTWRK Servers
•Workspace
•Set Projection
+Shortcuts
•Posts
•Story Mode
+The Framework
•Language
•Tools
•Trending Topics
+Events
+April
•Easter
+December
•Christmas
•Hanukah
+March
•Eid Mubarak
•Seasons
+TXTWRK
•Annual
+Films
+From TXTWRK to Film
•Our Trail To Work
+Person of Interest X 2025
•Preview
+The Super 10
•Preview
+Learn How To
•Social Media
+Our Feedback
+Companies
+Alphabet Inc
•YouTube
•Facebook
+Partners
+AI
•Microsoft
+Educational
•Derby College
+People
+Digital
•Steve Jobs
+Role Models
•Questions
+Shop
+Digital
•NFT The Platinum Collection
+Subscriptions
+From TXTWRK
•Monthly Tiers
+United Kingdom
+Guidance
•Startups
+Podcasts
•S1 E1 The Start
+Work
+Startup
•Kids
+World
•Pledges
•Politics





@TXTWRK



Topic: Servers
⛶
AI
Neutral
Working with AI lately has been particularly interesting in 2026 as we develop our workspace technologies that allow you to talk to AI, download your code stack, share it with AI and then update your app, website or service.

What’s coming up:
•Test.TXTWRK.com
•Experiments.TXTWRK.com

We are going global, so be sure to @TXTWRK:Checklists! & apply to our web development and server checklist.

Community Library: Gif
TXTWRK; Christmas, Christmas2025


⛶
Neutral
TXTWRK Workspace <> AI


Rollbacks, Downloads & the Future of Work

Development Report — Sunday, 25 October 2026

Building with AI. Working across servers. Keeping people in control.

---

1. Today's Development at a Glance


TXTWRK Workspace now brings AI-assisted development, server downloads, file history and rollback into one connected environment.

FeatureWhat&#039;s NewWhy It Matters
&lt;&gt; AI &lt;&gt;Export code to AI, inspect returned ZIPs and apply approved changesAI-assisted development with human control
Smart DownloadsSelect files, folders, extensions and size limitsDownload only what&#039;s needed
Basic RollbackRestore the previous saved versionRecover from mistakes
Power RollbackChoose an earlier version by dateGreater historical control
Rollback ExplorerFolder trees, version selectors and orange recent-edit dotsFind and restore files faster
Saved Path SetsRemember named groups of files and foldersReuse working configurations
Audit HistoryPersonal and server-wide edit recordsAccountability and traceability
Cross-Device SettingsPreferences saved on the connected ServerContinue work across devices
The result: A more connected workflow for managing source-code changes, whether made manually or with AI assistance.

---

2. <> AI <> — From Source Code to AI and Back


TXTWRK's new AI overlay helps people work with an AI client of their choice without requiring a repository migration.

``
YOUR CONNECTED SERVER
|
v
SELECT FILES / FOLDERS
|
v
DOWNLOAD AI ZIP
|
v
AI CLIENT OF CHOICE
|
v
RETURN UPDATED ZIP
|
v
INSPECT & APPROVE
|
v
APPLY TO LIVE FILES
|
v
SAVE VERSION + AUDIT
`

Example: Updating a website


A developer selects:

`
/index.php
/system/core/layout/
/system/core/workspace/
`

They download a ZIP, ask an AI assistant to improve the interface, then upload the returned ZIP into Workspace.

TXTWRK presents the changes for review. Once approved, the updated files are applied to their original server paths and version history is maintained.

Important: AI does not automatically decide what goes live. The authorised user reviews and confirms the changes.

---

3. Smart Downloads — Your Server, Your Selection


Users can download all eligible server files or specify exactly which paths to include.

ControlExample
Include paths/system/core/
Exclude folders/vendor/
Exclude mediaSkip common audio, video and image files
Exclude extensions.mp4`, .mp3, .zip, .log
Maximum file sizeSkip files larger than 10 MB
Include edit historyOptional .txtwrk version files
Named presetsWebsite Core, Community Project
### Hidden-file support

The export correction now supports legitimate hidden files, including:

``
/.htaccess
/system/core/1-images/.htaccess
`

Both paths were confirmed in a subsequent AI handoff ZIP.

The leading
/ identifies the connected Server's document root. Automatic AI imports still restrict replacement of sensitive infrastructure files such as .htaccess`.

---

4. Rollback — Two Methods, One History


TXTWRK now provides two ways to explore files for rollback.

My Recent EditsAll Dropdown Files
Files from your personal edit historyFiles across your saved selector groups
Focused on your own workFocused on your organised working environment
Useful for correcting recent changesUseful for finding project files
### Example: The Rollback Tree

``
▼ /system/
▼ core/
▼ layout/
● header.php
Version: v55 — 25 Oct 2026 ▼
Previous: v54

● post_script.php
Version: v18 — 25 Oct 2026 ▼

▼ workspace/
index.php
Version: v32 — 24 Oct 2026 ▼
`

● Orange indicator: Edited within the last seven days.

The tree supports folder expansion, search, historical dates and version dropdowns.

Two restoration choices

•Basic Rollback: Restore the immediately preceding saved version.
•Power Rollback: Select a particular historical version and restore it after confirmation.

Files without suitable history can still be displayed, but they cannot be rolled back until an earlier version exists.

---

5. File Versions, Logs & Remembered Settings


TXTWRK uses numbered
.txtwrk` files to preserve edit history.

Example: An AI update


``
BEFORE AI UPDATE
header.php
header.php.txtwrk.53
header.php.txtwrk.54

AI UPDATE APPROVED
|
v

AFTER AI UPDATE
header.php ← Latest content
header.php.txtwrk.53
header.php.txtwrk.54
header.php.txtwrk.55 ← New edit version
``

The version number advances according to that file's history.

Connected-server records


RecordPurpose
logs/master_log.phpServer-wide edit activity
logs/{user_id}/edits.phpIndividual member&#039;s edit history
logs/{user_id}/settings.phpSaved preferences and path sets
These records support accountability, recent-edit discovery and continuity between devices.

For example, a developer can save a Website Core path set on their desktop and access the same remembered settings when using Workspace on another device.

---

6. Workspace, Server & Checklists — How They Connect


These are distinct TXTWRK capabilities that complement one another.

ProductRole
ServerConnect and configure independently hosted infrastructure
WorkspacePrivate working environment for authorised server contributors
ChecklistsOrganise projects, groups, discussions, files and participation
ChecklistingChecklists a member is participating in
&lt;&gt; AI &lt;&gt;Extend Workspace with AI-assisted file changes
### Example: A community website project

``
COMMUNITY PROFILE
|
v
CHECKLIST: WEBSITE PROJECT
/Assets/
/Campaigns/
/Entities/
/Intelligence/
/Production & Procure/
|
v
VOLUNTEERS & CONTRIBUTORS
|
v
CONNECTED SERVER
|
v
AUTHORISED WORKSPACE TEAM
|
v
AI DEVELOPMENT + ROLLBACK
``

A Checklist can organise the project and welcome volunteers, while Workspace provides authorised developers with a separate environment for working on the connected Server.

This distinction allows communities to coordinate participation without granting everyone source-code access.

---

7. Who Benefits? Real-World Examples


AudienceExample Use
CommunitiesOrganise volunteers through Checklists while developers maintain the community website
StartupsImprove product code with AI and preserve earlier versions
StudentsLearn file structures, version history and responsible AI development
BusinessesManage selected directories and track authorised changes
ResearchersMaintain project files and structured working environments
Public-interest teamsReview and recover changes to community-facing digital services
### Example: A small startup

A startup maintains its product website on its own Server. Its founder saves a Product Interface preset, downloads the relevant source, asks an AI assistant to improve mobile navigation, and reviews the returned ZIP.

If a problem appears after deployment, the team can locate the affected file and restore a previous version.

The benefit is not simply faster code generation. It is a more organised process for making and recovering changes.

---

8. The Future of Work — Why This Matters


TXTWRK is bringing together four essential elements:

``
PEOPLE
|
v
CONNECTED WORKFLOWS
``

What makes this direction important?

•Choice: Users can work with independently connected Servers and AI clients of their choice.
•Control: Users select what is exported and approve what is applied.
•Continuity: Saved path sets and edit history support ongoing work.
•Recovery: Rollback provides a route back to earlier versions.
•Opportunity: Communities, startups and individuals can use related tools within one wider network.

What comes next?


Further priorities include visual code comparisons, stronger multi-file recovery, improved security review and more extensive live integration testing.

Today's development passed local PHP and JavaScript checks and interface tests, and the hidden-file export correction was confirmed in a downloaded archive. Full end-to-end production validation of the AI import and deployment workflow remains important.

---

Closing Statement


25 October 2026 represents a meaningful development milestone for TXTWRK Workspace.

What began as a connected environment for working with server files is expanding into a system that supports AI-assisted changes, portable working configurations, historical restoration and accountable development.

TXTWRK's wider ambition is to connect people, communities, projects and infrastructure—making sophisticated digital work more accessible without taking control away from the people responsible for it.

AI helps create. TXTWRK helps organise, apply and recover. People remain in control.

TXTWRK.com | Building the next experiences together.

@TXTWRK!

1/6
🗖 VIEW
⛶
Technology
Neutral
TXTWRK: The Complete Platform Guide


Communities, Knowledge, Work, Business and Connected Infrastructure


The Friday Update — 23 October 2026

Nearly three years of development. A 1,000-year vision. One connected platform.

Welcome to TXTWRK


TXTWRK is being developed as a connected environment for people, communities, organisations, businesses and projects.

It combines social communication with practical tools for organising information, working together, developing ideas, managing resources and connecting existing websites.

The platform is built around a simple belief:

A digital community should be able to do more than communicate. It should be able to build, organise, collaborate and preserve the value of its work.

TXTWRK brings together several major areas:

1. Personal profiles, identity and social connections.
2. Posts, discussions, topics and community activity.
3. Checklists and collaborative workspaces.
4. Connected Servers and file infrastructure.
5. Direct and group messaging.
6. Business and organisational participation.
7. Products, purchases, investments and subscriptions.
8. Events, calendars, locations and education.
9. Community resources, directories and libraries.
10. APIs, integration tools and developer infrastructure.
11. Notifications, reporting, moderation and safety.
12. Long-term knowledge and community development.

These areas are supported by the platform's expanding /system/core/ architecture.

This guide introduces what users can explore, explains the principal workflows and highlights the latest development work.

---

PART ONE — GETTING STARTED


1. Create your TXTWRK identity


Your account is the starting point for participation.

TXTWRK supports personal profiles, usernames, profile images, account information and connections between members.

How to begin


1. Visit https://txtwrk.com.
2. Register or sign in.
3. Open your profile.
4. Review your account information and profile presentation.
5. Explore the available profile, connection and participation controls.
6. Begin discovering people, topics and communities.

The platform includes functionality for profile editing, following, account connections, user information, profile media and additional profile-related settings.

Why it matters: A profile gives contributions an identifiable place within the wider TXTWRK community.

2. Discover the platform


TXTWRK contains search and discovery functionality for posts, users and topics.

You can use discovery to find conversations, people and subjects relevant to your interests.

The platform also includes location-based data structures and tools that can help organise information geographically.

Getting started: Search for a subject you care about, explore the relevant content and follow the people or discussions you want to revisit.

3. Build your network


TXTWRK includes following and connection functionality.

Members can develop relationships around shared interests, projects, business activities and community participation.

Connections are especially useful when a conversation develops into an ongoing collaboration.

---

PART TWO — COMMUNICATION AND COMMUNITY


4. Posts and discussions


Posts are one of TXTWRK's central ways of sharing information.

The platform includes systems for creating and retrieving post content, working with images and videos, following posts, managing topics and reporting content.

A post might introduce:
•An idea or proposal.
•A community announcement.
•A project update.
•A question or discussion.
•A business opportunity.
•A research subject.
•An event or activity.

How to participate


Find a post that interests you, read its context and use the available interaction controls to contribute.

Where supported, attach relevant media or link to related material.

Good practice: Keep the main subject clear so that later contributions remain understandable.

5. Topics and subject discovery


Topics help organise participation around subjects rather than leaving every discussion isolated.

TXTWRK includes topic-related functionality for posts, Checklist comments and replies, together with topic search and management components.

Topics are useful for connecting conversations about science, technology, business, education, local communities, culture and other fields.

They also support the platform's wider ambition to connect related knowledge across different types of content.

6. Replies and Threadlets


TXTWRK's discussion model can extend beyond a simple sequence of comments.

Within Checklists, replies can contain Threadlets: deeper conversational contributions connected to a particular reply.

This allows a discussion to develop in context.

For example:

Checklist item → Comment → Reply → Threadlet → Further Threadlet

Threadlets are useful when a reply generates its own detailed discussion.

Recent development work has strengthened direct linking, media handling and moderation of these conversations.

7. Direct and group messaging


TXTWRK includes messaging functionality for individual conversations and groups.

The source system contains components for direct chat, group creation, group membership, message reading, media uploads, audio storage and message management.

How communities can use messaging


Direct messages can support individual coordination.

Group conversations can help members organise around a shared project or purpose.

Messaging can complement public posts and Checklists when a smaller conversation is more appropriate.

The platform also includes Connected Server-related messaging settings and communication infrastructure.

8. Notifications and All Activity


Notifications help members identify relevant interactions and developments.

All Activity provides a broader way of recording and presenting actions associated with participation.

The platform includes notification retrieval, read status, notification preferences and activity-related APIs.

These systems help users follow developments without manually revisiting every conversation.

Recent moderation improvements also address the cleanup of activity and notification records when Checklist contributions are hidden or deleted.

---

PART THREE — CHECKLISTS AND COLLABORATIVE WORK


9. Understanding Checklists


Checklists are among TXTWRK's most substantial collaborative features.

They bring structured items together with discussion, participation, supporting files and ongoing activity.

A Checklist can support:
•A community project.
•A research initiative.
•A development plan.
•An organisation's work programme.
•An educational activity.
•A creative production.
•A long-running public-interest subject.

Unlike a conventional task list, the TXTWRK Checklist system connects the work itself with conversations and supporting resources.

10. Checklist items


Each Checklist can contain individual items representing areas of work or subjects requiring attention.

The system includes item editing, details, topics, relevance controls and associated discussions.

Practical workflow


1. Open a Checklist.
2. Select an item.
3. Read the item's details and associated contributions.
4. Add a comment or reply where permitted.
5. Follow subsequent discussion and updates.
6. Use linked resources where available.

The item becomes a central point for both the work and its history.

11. Checklist comments and replies


Checklist comments provide a way to contribute directly to an item.

Replies allow other participants to respond to a particular comment.

The platform also supports acknowledgements, pinned contributions, topic associations and reporting functionality.

This creates a more organised discussion model than a single undifferentiated comment feed.

12. Checklist participation and applications


TXTWRK includes functionality for Checklist applications, applicant responses, member management and applicant messaging.

This allows Checklist participation to involve more than simply reading public content.

Depending on the Checklist's configuration and permissions, people may apply to participate and gain access to relevant collaborative capabilities.

13. Checklist moderation


The platform includes moderation controls for Checklist comments, replies and Threadlets.

These include hiding, soft deletion, reporting and other administrative actions.

Recent improvements support:
•Preserving underlying contributions and relationships.
•Removing associated activity and notifications where appropriate.
•Moderating individual Threadlets.
•Moderating an entire descendant Threadlet branch.
•Keeping contributions above a moderated branch unaffected.

This approach helps communities maintain readable discussions while preserving important structural information.

14. Checklist templates and reuse


The source system includes Checklist templates, design controls, copying functionality and downloadable data components.

These can support repeatable work across similar projects.

For communities, reusable structures can reduce the effort involved in starting a new initiative.

---

PART FOUR — CONNECTED SERVERS AND FILES


15. Connect an existing website


TXTWRK's Connected Server system is intended to make existing infrastructure useful within the platform.

A community may already operate a website with files, folders and resources.

Instead of rebuilding everything from scratch, its owner can connect that Server to TXTWRK.

The platform includes Server registration, verification, ownership checks, settings and supporting APIs.

Typical setup


1. Open the Server management area.
2. Add the website or Server.
3. Complete the required verification process.
4. Configure its supported capabilities.
5. Review which files and folders may be made public.
6. Connect the Server to relevant TXTWRK functionality.

The exact deployment requirements depend on the connected Server's endpoint and configuration.

16. Public Files / Folders


Server owners can specify which paths should be publicly accessible through TXTWRK's supported directory integrations.

The latest update introduces three complementary settings:

Public folders — directories available for public browsing.

Public files — individual files available for public browsing.

Excluded files / folders — paths removed from public TXTWRK directory access, even when they fall inside a public folder.

For example:

Public folder: /

Excluded paths:
•/includes/
•/.env
•/private/
•/TXTWRK.php

This can make it easier to integrate an existing root-built website while excluding selected internal resources.

Security reminder: These exclusions control TXTWRK directory visibility. They do not block direct requests to the connected website. Sensitive resources must also be protected by the Server's own authentication and access controls.

17. Checklist File Explorer


The Checklist File Explorer connects a Checklist workspace with files on its associated Server.

The system distinguishes between the Server owner, authorised Checklist members and public visitors.

Depending on permissions, users may be able to browse directories and perform supported file operations.

The interface includes controls for navigating the Server root, returning to the Checklist root, opening a member directory, refreshing the listing and filtering visible entries.

Supported management components include creating folders and files, renaming, moving and deleting resources.

The directory system also contains reference-synchronisation functionality to help keep related references aligned after file operations.

18. Media and connected resources


TXTWRK includes support for images, video, audio and file attachments across different areas of the platform.

Connected media can link discussions with resources hosted on an associated Server.

Recent improvements have focused on media rendering and handling within Checklist conversations and Threadlets.

For community projects, this allows supporting resources to remain associated with the discussion that gives them meaning.

---

PART FIVE — BUSINESS, PRODUCTS AND INVESTMENT


19. Business profiles and participation


TXTWRK includes business-oriented profile and application components.

The platform source contains business registration, business profile, business intelligence and business application functionality.

These systems establish a foundation for businesses and organisations to participate alongside individuals and communities.

Potential uses include presenting organisational information, engaging with relevant topics and connecting opportunities to community discussion.

20. Products and purchases


TXTWRK contains a substantial product-related subsystem.

The source includes product retrieval, product APIs, purchase availability checks, purchase reservations and purchase recording.

It also contains a Product Logbook system with functionality relating to product details, claims, history, buying and resale.

This indicates an approach in which products can have associated records and activity rather than existing only as isolated listings.

The availability of individual purchasing features depends on the relevant product and account configuration.

21. Investments and funding


Investment-related functionality is another major part of TXTWRK's architecture.

The system includes components for:
•Retrieving investment information.
•Recording investments.
•Reserving and cancelling investment opportunities.
•Checking investment status.
•Investment approvals.
•Funding details.
•Investment-related APIs.

This creates a basis for connecting financial and developmental opportunities with the wider platform.

Users should review the specific terms and status of any opportunity before treating it as available or actionable.



@TXTWRK:Invest! represents a way to bring ideas and opportunities into the TXTWRK investment conversation.

The concept can be relevant across different topic types, including business, science, education, technology, culture, community infrastructure and research.

A useful contribution explains:
•What the opportunity is.
•Why it matters.
•Who could benefit.
•What resources or collaboration may be required.
•What long-term value it could create.

The tag is a call for attention and discussion, not an automatic funding decision.

23. Subscriptions and account tiers


TXTWRK includes account-tier, subscription and payment-related functionality.

The source contains subscription processing, subscription status, profile subscription records and account-tier management components.

These systems can support different types of access or commercial participation where enabled.

Users should consult the actual account interface for current terms, availability and pricing.

---

PART SIX — LOCATIONS, EVENTS AND EDUCATION


24. Locations and geographical context


TXTWRK contains an extensive location subsystem.

It includes location records, country-level information, location search and suggestions, geographic relationships, addresses and location-linked content.

This can help connect digital participation to real places.

For communities, geographical context is particularly useful when a project relates to a neighbourhood, region, country or physical venue.

25. Events and calendars


The platform includes event-related APIs, event retrieval, calendar data and calendar-management components.

Events can help communities connect ongoing discussion with activities occurring at particular times.

The broader data structure also supports event information organised by location and subject.

26. Education and learning


TXTWRK includes education-related components and learning-oriented calendar data.

These establish a foundation for connecting knowledge, events and community participation.

The long-term opportunity is to make learning part of ongoing community activity, rather than separating it entirely from practical projects and discussion.

---

PART SEVEN — COMMUNITY RESOURCES AND STRUCTURED INFORMATION


27. Directories and community libraries


The platform includes directory creation, file retrieval, directory management and community library components.

These provide infrastructure for organising and accessing resources.

A directory can help people find relevant information, while a library can provide a more enduring place for material connected to a community.

28. Structured linking and relationships


TXTWRK includes a substantial linking subsystem, with APIs for retrieving, updating, rendering and structuring linked information.

The source also contains structured data fields associated with community roles, community impact, locations and other classifications.

These systems are significant because they offer ways to connect information beyond simple text matching.

Over time, structured relationships can make it easier to discover how people, places, subjects and projects relate to one another.

29. Questionnaires, feedback and voting


TXTWRK includes questionnaire management, profile questionnaire components, feedback and question-voting functionality.

These can support collecting opinions and structured responses.

Such tools are useful when communities need more than an open discussion and want to gather information in a consistent form.

30. Audio and live participation


The source includes audio-room actions, Checklist-related audio-room components, audio updates and discussion-audio functionality.

Audio offers another mode of participation alongside written discussion and media attachments.

Specific room capabilities and availability should be confirmed through the live interface.

---

PART EIGHT — DEVELOPERS AND THE API KIT


31. Understanding the TXTWRK API architecture


The API toolkit is a key part of the platform's technical direction.

The source includes APIs for:
•Checklist and Server integration.
•Directory retrieval and management.
•Events and calendars.
•Activity records.
•Structured linking.
•Locations.
•File uploads.
•Server-side operations and reference synchronisation.

The platform also includes Server endpoint templates and supporting runtime components.

32. Why this matters for communities


Many communities already have websites, file stores and established workflows.

An API-based approach offers a way to connect those resources with TXTWRK without requiring every organisation to adopt the same infrastructure.

A developer might use the available integration components to connect an existing website with a Checklist workspace or make approved resources accessible through TXTWRK.

The important principles are:

Ownership: Communities should understand which infrastructure they control.

Interoperability: Different systems should be able to communicate through defined interfaces.

Permissions: Integration should not bypass access controls.

Continuity: Existing resources should remain useful as the platform develops.

33. Getting started as a developer


A practical development workflow is:

1. Review the Connected Server setup.
2. Identify the relevant Server endpoint and deployment requirements.
3. Complete ownership verification and authentication configuration.
4. Test the supported operations with non-sensitive resources.
5. Configure public directory grants and exclusions.
6. Connect the Server to a suitable Checklist or workspace.
7. Confirm access from different account and permission levels.
8. Review logs, errors and integration behaviour before wider use.

Important: The existence of an API file does not itself establish that it is a documented, stable or publicly supported endpoint. Developers should use the published integration contract for the specific functionality they intend to deploy.

---

PART NINE — SAFETY, PERMISSIONS AND TRUST


34. Moderation and reporting


TXTWRK includes reporting systems for posts, Checklist comments and replies, together with safety-related functionality.

Members should use the available reporting tools when content requires review.

Administrators and moderators should apply the permissions appropriate to their responsibilities.

35. Access and ownership


Access can differ between public visitors, ordinary members, Checklist contributors, moderators, Server owners and administrators.

The Connected Server model makes this especially important.

A resource being visible in one context does not necessarily mean every user should be able to modify it.

36. Preserving contribution history


Recent Checklist and Threadlet work reflects an important distinction between removing content from ordinary display and permanently destroying its underlying records.

Where supported, moderation can preserve original relationships and records while controlling visibility.

This is especially relevant to long-running communities that need to understand how decisions and discussions developed.

---

PART TEN — THE FRIDAY UPDATE


37. What has changed recently?


The latest development work has concentrated on connecting the platform's different systems more effectively.

Platform structure


Continued consolidation around /system/core/, providing a clearer home for shared functionality, APIs, workspaces and supporting services.

Connected Servers


Improved support for existing websites, including root-level public directory configuration and explicit file/folder exclusions.

Checklist directories


Enhanced file exploration, workspace permissions, directory navigation and file-reference handling.

Threadlets


Improved deep linking, moderation, branch handling and media integration.

Checklist moderation


Updates to comment and reply handling, with associated activity and notification cleanup.

Media


Refinements to connected media rendering and supported attachments.

Reliability


Further work on JavaScript compatibility, response handling, error reporting and directory loading.

These updates are part of a continuing engineering process. Individual fixes require deployment and live verification before they can be considered fully resolved.

---

PART ELEVEN — OUR 1,000-YEAR DIRECTION


38. Why think 1,000 years ahead?


TXTWRK's 1,000-year horizon is a principle for thinking about long-term value.

It encourages us to ask whether today's systems can help future communities understand the work, decisions and knowledge of those who came before them.

That means thinking about:
•Preserving context.
•Keeping information understandable.
•Supporting independent communities.
•Designing adaptable infrastructure.
•Building relationships between knowledge and practical work.
•Maintaining continuity through technological change.

The aim is not to promise that today's software will remain unchanged for a millennium.

It is to make long-term usefulness a continuing priority.

39. Nearly three years of TXTWRK


As TXTWRK approaches its third year, the scale of its ambition is becoming more visible.

The platform now brings together systems for communication, collaboration, business activity, investment, structured information, Server integration and community participation.

The challenge ahead is to make those capabilities increasingly accessible, reliable and understandable.

This Friday is therefore both a milestone and a starting point.

A milestone because of the substantial work already completed.

A starting point because the value of the platform will ultimately be measured by what people and communities can do with it.

---

A SIMPLE GUIDE TO YOUR FIRST TXTWRK PROJECT


For someone arriving at TXTWRK for the first time, the following journey brings the major concepts together.

Step 1 — Join TXTWRK. Create an account and establish your profile.

Step 2 — Discover a subject. Search for a person, topic, post or community relevant to your interests.

Step 3 — Participate. Contribute to a discussion or follow an existing project.

Step 4 — Explore a Checklist. Open a Checklist item, read its contributions and understand how work is organised.

Step 5 — Collaborate. Where authorised, apply to participate, contribute replies and engage in deeper Threadlet discussions.

Step 6 — Connect resources. If you own a website or Server, explore the Connected Server setup and configure access appropriately.

Step 7 — Organise supporting files. Use the available Checklist directory features within your permissions.

Step 8 — Explore the wider ecosystem. Discover business profiles, products, investment opportunities, events, locations and other supported platform areas.

Step 9 — Develop your network. Connect with people who share your interests or work.

Step 10 — Think long term. Consider how your contributions could remain valuable beyond the immediate conversation.

---

OUR MESSAGE TO THE COMMUNITY


TXTWRK is not simply about posting information. It is about connecting people with the ability to do something meaningful with that information.

A conversation can lead to a Checklist.

A Checklist can become a collaborative project.

A project can connect to real files, people, locations and resources.

A community can bring its existing website into that environment.

An idea can become an opportunity for development, learning, investment or wider participation.

This is the connected future we are working towards.

Nearly three years into the journey, we remain committed to shaping a platform that serves today's communities while keeping future generations in mind.

TXTWRK — Connect. Contribute. Collaborate. Build for the future.

@TXTWRK:Invest!

Friday, 23 October 2026

---

PART TWELVE — HOW TXTWRK COMPARES WITH GITHUB, FACEBOOK WORKPLACE AND GOOGLE WORKSPACE


40. Different platforms, different foundations


TXTWRK's approach brings together social participation, practical collaboration, Connected Servers, structured community knowledge and a publicly accessible development environment.

To understand this direction, it helps to compare TXTWRK with established platforms serving different needs.

GitHub is primarily a software development and code collaboration platform.

Facebook Workplace was designed for internal workplace communication and organisational communities. Meta discontinued Workplace as a normal operating product after 31 August 2025, with deletion of customer data scheduled for 31 May 2026.

Google Workspace provides business productivity and communication applications, including Gmail, Drive, Docs, Sheets, Meet and Calendar.

TXTWRK is developing a broader community-oriented model that combines social participation, Checklists, Connected Servers, structured discussions, business functionality and developer integrations.

The aim is not to claim that these platforms are identical or interchangeable. It is to explain the different problems they are designed to solve.

41. Platform comparison


CapabilityTXTWRKGitHubFacebook WorkplaceGoogle Workspace
Primary purposeConnected communities, projects and resourcesSoftware development and code collaborationInternal organisational communicationBusiness productivity and collaboration
Personal profilesYesDeveloper profilesEmployee profilesOrganisational accounts
Public social discussionsPosts, topics and community interactionIssues, Discussions and repositoriesPrimarily private workplace communitiesNot a primary public social-network function
Structured collaborative workChecklists and associated discussionsIssues, Projects and pull requestsGroup and workplace collaborationDocs, Sheets, Tasks and other applications
Nested discussionsChecklist replies and ThreadletsThreaded review and discussion featuresGroup discussions and commentsDocument comments and conversations
Source-code hostingNot established as a Git repository hosting equivalentCore capabilityNot a core capabilityNot a core capability
Live public development and learningPart of TXTWRK&#039;s stated development approachPublic repositories and open-source collaborationNot its primary purposePrimarily application-based collaboration
Existing website integrationConnected Servers and API kitAPIs, webhooks and integrationsHistorical enterprise integrationsAPIs, Apps Script and integrations
Connected file explorationChecklist File ExplorerRepository file browserWorkplace file sharingGoogle Drive
Community participation applicationsChecklist applications and membershipOrganisation and repository permissionsWorkplace membershipOrganisational access controls
Direct and group messagingMessaging componentsLimited direct messaging focusWorkplace Chat historicallyGoogle Chat
Business participationBusiness-related subsystemOrganisations and developer businessesOrganisational communicationBusiness accounts and productivity
Product and purchase recordsProduct and Product Logbook componentsNot a primary native commerce functionNot a primary native commerce functionUsually handled through integrations
Investment-related componentsInvestment and funding subsystemNot a primary native functionNot a primary native functionNot a primary native function
Events and calendarsEvent and calendar componentsIntegrations and project milestonesWorkplace event-related features historicallyGoogle Calendar
Long-term community visionExplicit 1,000-year design horizonLong-term software collaborationDiscontinued productOngoing productivity ecosystem
Comparison note: TXTWRK entries describe the platform architecture and stated direction; individual live workflows may vary. Other platform entries describe their general product focus, not an exhaustive feature audit.

42. TXTWRK and GitHub — Public code, public learning


GitHub has played a major role in making open-source software collaboration accessible.

Developers can publish repositories, review changes, submit pull requests, report issues and maintain software projects together.

TXTWRK approaches public collaboration from a different starting point.

Its focus is not limited to software repositories.

It connects technical development with community discussions, Checklists, files, resources, organisations and opportunities.

TXTWRK's own public, working development approach is especially relevant here.

We want people to be able to observe how systems are built, understand how different components connect and learn from practical implementations.

Our growing /system/core/ structure and API kit represent an effort to organise this work into a more coherent technical foundation.

The distinction: GitHub specialises in managing code collaboration. TXTWRK aims to connect technical development with the broader community and practical work surrounding it.

Being publicly viewable or downloadable is not, by itself, the same as being open source under a recognised licence. Public TXTWRK code should therefore include clear licensing, contribution instructions and security guidance so developers know exactly how they may reuse it.

43. TXTWRK and Facebook Workplace — Beyond internal communication


Facebook Workplace focused on communication within organisations.

It brought familiar social interaction patterns into the workplace, helping employees communicate through groups, posts and messaging.

Its discontinuation illustrates an important issue for organisations that depend on a single hosted communication product: service continuity matters.

TXTWRK's Connected Server direction addresses a related concern from another angle.

Communities can connect infrastructure they already operate rather than placing every resource inside one centrally hosted workspace.

A Checklist can organise the work, while the associated Server can continue hosting relevant resources.

This does not make TXTWRK independent of every central service or eliminate hosting risks. It does, however, establish a model in which connected resources can remain under the Server owner's control.

The distinction: Workplace was primarily an internal communication product. TXTWRK is pursuing a wider combination of public communities, structured collaboration and connected infrastructure.

44. TXTWRK and Google Workspace — Connecting productivity with communities


Google Workspace is a mature collection of productivity applications.

Its strength lies in tools such as shared documents, spreadsheets, email, calendars, meetings and cloud storage.

TXTWRK does not need to replicate every office application to serve a different purpose.

Its Checklists, discussions, Threadlets and Connected Servers offer a model in which people can organise projects and connect existing resources.

For example, a community could maintain documents on its own Server, connect the appropriate directories to a Checklist and discuss the work through TXTWRK.

The value lies in connecting resources with participation and context.

The distinction: Google Workspace specialises in productivity applications. TXTWRK aims to organise broader community activity around work, knowledge, discussions and independently hosted resources.

45. Why our live, public, open-source learning direction matters


TXTWRK's development philosophy places value on making technical work understandable and useful.

A public working system can help people learn from real implementation choices, rather than relying exclusively on abstract demonstrations.

The API kit supports this direction by offering a route for existing websites and community systems to connect with TXTWRK.

The /system/core/ restructuring provides a more organised foundation for that development.

Connected Servers allow communities to bring their own infrastructure.

Checklists provide structured places for collaborative work.

Threadlets preserve conversational depth.

Together, these elements help explain the kind of platform we are building.

Our long-term objective is to make participation meaningful for both technical and non-technical communities.

Public code. Practical learning. Connected infrastructure. Community development.

These principles are intended to reinforce one another.

46. The bigger difference: thinking beyond the next product cycle


The most significant difference may not be any individual feature.

It is the question guiding the platform.

What would digital infrastructure look like if we continually considered its value over the next 1,000 years?

For TXTWRK, that means keeping attention on continuity, knowledge, relationships, independent infrastructure and the ability of future communities to build on existing work.

GitHub demonstrates the importance of collaborative software development.

Google Workspace demonstrates the value of integrated productivity.

Workplace's history demonstrates why organisations should consider continuity and dependence on particular services.

TXTWRK can learn from these examples while developing its own identity.

Our ambition is to connect communities with the tools, resources and opportunities needed to build lasting value.

---

FINAL WORD — NEARLY THREE YEARS, WITH 1,000 YEARS IN MIND


This Friday represents more than another platform update.

It reflects nearly three years of developing an increasingly connected system for people, communities, organisations and projects.

From posts and discussions to Checklists and Threadlets.

From business and investment systems to events, education and community libraries.

From Connected Servers to a growing API toolkit.

From everyday participation to the preservation of knowledge over generations.

TXTWRK is working towards a platform where people can connect, learn, contribute, collaborate and build without losing sight of the future.

We welcome people with existing websites, established communities, new ideas, technical knowledge and practical projects.

We want TXTWRK to become a place where those different contributions can connect.

And we want to continue learning publicly as the system develops.

Nearly three years of development.

One connected platform.

A 1,000-year vision.

TXTWRK — Connect. Contribute. Collaborate. Build for the future.

@TXTWRK:Invest!

Friday, 23 October 2026



⛶
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:

ProductProposed Starting PricePurpose
TXTWRK Server OneFrom £1,000Home hosting for businesses and communities
TXTWRK Servers: Local Open ComputeFrom £3,000Server 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


LayerFunction
Local interfaceDevice management, storage, applications and networking
TXTWRK platformAccounts, domains, licensing, support and partner integrations
Partner servicesWebsite builders, management panels, security and backup
Server operating environmentHosting, containerization, updates and monitoring
Network servicesOptional 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


ComponentProposed Requirement
CPUEfficient multicore processor
RAMExpandable memory
StorageSSD-based system and application storage
NetworkingReliable Ethernet connectivity
SecuritySecure boot, encryption and authenticated identity
CoolingEfficient, maintainable cooling
PowerLow idle consumption and safe shutdown
ConstructionRepairable and replaceable components
SoftwarePreinstalled 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.

ResourceInitial AllocationPurpose
Total dedicated network storage1 TBDistributed network participation
CDN-style cache100 GBFrequently requested content
Remaining storage900 GBOther approved network storage workloads
CPUTo be specifiedIndependent processing tasks
GPUModel-dependentSupported accelerated workloads
BandwidthManaged allocationNetwork 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.

MechanismProposed Approach
Storage contributionsReward verified useful capacity and availability
Compute contributionsReward successfully completed workloads
Bandwidth contributionsReward approved data delivery
CompensationTXTWRK credits
RedemptionOptional periodic cash settlement
Settlement frequencyQuarterly, 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 ConditionPotential Role
New high-performance deviceAdvanced applications and compute
Mature deviceGeneral hosting and distributed storage
Older compatible deviceCaching and lightweight processing
Limited-capacity deviceMonitoring or other low-demand services
Unsupported or unsafe deviceRetirement, 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 CategoryPotential Contribution
Hardware manufacturersComponents and modular server designs
Hosting companiesDomain services and management tools
Network operatorsConnectivity and routing expertise
Cloud providersHybrid compute and storage
CDN operatorsContent delivery integration
Security companiesDevice trust and threat protection
UniversitiesResearch and independent testing
Software developersApplications 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 ServersRaw Network StorageCDN Cache Allocation
100100 TB10 TB
1,0001 PB100 TB
10,00010 PB1 PB
100,000100 PB10 PB
1,000,0001 EB100 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


ChallengeResearch Response
Residential upload limitationsBenchmarking and workload selection
Dynamic IP addresses and NATSecure tunnels and connectivity services
Unreliable nodesRedundancy and automated recovery
Hardware differencesStandardized compatibility profiles
Data securityEncryption and isolation
Network economicsUsage metering and resource accounting
Electricity costsEnergy-efficient scheduling
Long-term supportModular design and compatibility policies
Legal complianceData protection and regulatory assessment
---

Part Six — Development Roadmap


24. Proposed Development Phases


PhaseObjectivePrincipal Deliverable
1Product definitionUser experience and hardware requirements
2Standalone prototypeWorking TXTWRK Server
3Platform integrationTXTWRK account and partner connectivity
4Distributed researchSmall Local Open Compute test network
5Pilot deploymentReliability and performance measurements
6Commercial validationManufacturing and economic assessment
7Controlled expansionAdditional 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


⛶
Technology
Neutral
TXTWRK — FULL DEVELOPMENT & API CONSOLIDATION REPORT


Report Date: 13 October 2026
Project: TXTWRK
Subject: Original Directory API Kit, Server API Kit and Messaging API Kit compared with the consolidated Workspace, Checklist and Messaging platform.

---

1. EXECUTIVE SUMMARY


TXTWRK began with three principal API kits:

1. Directory API Kit
2. Server API Kit
3. Messaging API Kit

The objective was to consolidate these technologies into one connected infrastructure that would allow users to manage files, communicate, collaborate and use their own Connected Servers for storage.

The project has progressed from individual API capabilities into a broader platform consisting of:
•Connected Server infrastructure
•Workspace file management
•Checklist collaboration
•Messaging and private media
•Shared filesystem operations
•Centralised access control
•Attachment reference synchronisation
•Media processing and thumbnails
•Integrated directory viewers
•Mobile-responsive overlays

The most important achievement is the separation of storage, identity, permissions and collaboration records while allowing these systems to operate together.

The remaining development concerns primarily involve file-reference integrity, deletion handling, thumbnail synchronisation and complete cross-kit verification.

---

2. ORIGINAL DIRECTORY API KIT


Original Purpose


The Directory API Kit provided the foundation for managing files and folders through TXTWRK.

Its responsibilities included:
•Browsing directories
•Listing files and folders
•Creating files
•Creating folders
•Uploading files
•Downloading files
•Renaming files and folders
•Moving files and folders
•Deleting files and folders
•Accessing authorised server directories

Development Progress


The Directory API functionality has been integrated into both Workspace and Checklist.

Workspace provides general-purpose file management.

Checklist provides a more restricted directory experience associated with a particular Checklist, its selected Connected Server and its participants.

Current Architecture


The Directory API is no longer best understood as a completely independent user-facing feature.

It provides reusable filesystem functionality that other TXTWRK kits consume.

Assessment


Status: Implemented and integrated.

Additional work remains to ensure deletion and reference synchronisation behave consistently across every consuming feature.

---

3. ORIGINAL SERVER API KIT


Original Purpose


The Server API Kit established the connection between TXTWRK Central and a user's Connected Server.

Its responsibilities included:
•Server registration
•Server verification
•Remote agent installation
•Server identification
•Secret-based authentication
•Signed API requests
•Remote filesystem operations
•Server ownership and permissions

Server Verification


The original verification process was designed to confirm that:

1. /TXTWRK.php was installed.
2. The server executed PHP correctly.
3. The remote agent possessed the expected secret.
4. The server identified itself correctly.
5. The server supported the required TXTWRK protocol.

Server URLs and secrets were resolved centrally rather than accepted directly from browser input.

Consolidated Architecture


The Connected Server model now supports multiple application features.

The general request flow is:

TXTWRK Interface
↓
TXTWRK Central API
↓
Session and Permission Validation
↓
Connected Server Selection
↓
Signed API Request
↓
Customer's /TXTWRK.php Agent
↓
Filesystem Operation
↓
Operation Result
↓
TXTWRK Central

The central API uses signed requests incorporating a timestamp, nonce and HMAC-SHA256 authentication.

Development Achievement


The Server API provides a common infrastructure for:
•Workspace operations
•Checklist directories
•Messaging media storage
•Authorised file access
•Remote uploads and downloads

Assessment


Status: Core architecture implemented.

Complete security and production-readiness verification still requires end-to-end testing.

---

4. ORIGINAL MESSAGING API KIT


Original Purpose


The Messaging API Kit was designed to provide private communication while allowing users to store media through Connected Servers.

The original concept included:
•Personal conversations
•Group conversations
•Private file sharing
•Server-backed media uploads
•Multimedia previews
•Downloadable attachments
•User-controlled storage capacity

Consolidated Messaging Architecture


Messaging now participates in the common Connected Server model.

The reviewed central gateway supports:
•Personal Messaging identity
•Delegated @MessagingAccess identity
•Accepted Messaging Access grants
•Group upload authorisation
•Direct-message upload authorisation
•Server-backed media storage

Important Architectural Separation


Messaging identity and storage entitlement are not the same thing.

A user may be authorised to store files on a particular Connected Server without representing that server owner's Messaging identity.

This allows TXTWRK to distinguish:

Who is communicating?

from:

Which Connected Server may store the files?

Assessment


Status: Shared storage authorisation implemented.

The complete Messaging attachment lifecycle still requires verification, particularly Rename, Move, Delete and database-reference consistency.

---

5. WORKSPACE KIT


Purpose


Workspace is TXTWRK's general-purpose file-management and working environment.

It uses the Connected Server infrastructure to perform authenticated filesystem operations.

Implemented Functionality

•Directory browsing
•File and folder listing
•File creation
•Folder creation
•Uploads
•Downloads
•Rename
•Move
•Delete
•File editing
•File versions
•Edit locks
•File ownership checks
•Edit requests
•ZIP compression
•ZIP extraction
•Delegated File Access
•Checklist integration

Original Compatibility


The early Workspace implementation preserved the existing manage.php action contract.

This allowed the original browser interface to continue functioning while filesystem operations were routed through the Connected Server agent.

Checklist Integration


Workspace became aware of Checklist file relationships.

When supported Checklist files or directories are moved, the Workspace implementation can invoke central reference synchronisation.

This is important because files are no longer treated solely as independent filesystem objects.

They may also be attachments belonging to Checklist comments, replies or Threadlets.

Assessment


Status: Implemented with substantial integration.

Remaining work concerns consistency after deletion, partial failures and cross-feature reference updates.

---

6. CHECKLIST KIT


Purpose


Checklist provides task-oriented collaboration connected to files, participants and discussions.

Core Functionality

•Checklist creation and organisation
•Checklist items
•Grouped items
•Item navigation
•Checklist overlays
•Applications
•Apply Now
•Active participants
•Comments
•Replies
•Threadlets
•Connected files
•Member directories
•File viewers
•Activity information

Connected Server Integration


Each Checklist can be associated with a selected Connected Server.

The directory system operates within the Checklist's authorised context.

The later gateway implementation checks the relationship between:
•Checklist ID
•Server ID
•Checklist owner
•Active participant
•Requested member directory

This helps prevent Checklist directory access from becoming unrestricted Workspace access.

Comments and Replies


The discussion system supports attached files and richer content.

The reviewed work includes:
•Comment attachments
•Reply attachments
•File listings
•Image previews
•Video previews
•Thumbnail handling
•Formatting controls
•Comment sorting
•Reply interactions
•Web Impression content

Threadlets


Threadlets extend Checklist conversations with nested discussion.

Development work included:
•Nested Threadlet presentation
•New Threadlet controls
•Connected file lists
•Image and video attachments
•Primary media previews
•Thumbnail handling
•Pagination
•Mobile indentation
•Visual discussion boundaries

Threadlet attachments use an independent database structure, including threadlet_media_files.

Mobile Development


Recent work addressed:
•Safari overlay scrolling
•Background-page scroll interference
•Checklist scroll-container targeting
•Apply Now navigation
•Dynamic comment viewers
•Web Impression display
•Threadlet presentation

The revised Apply Now behaviour was reported working after testing.

Assessment


Status: Broad functionality implemented and actively refined.

Some attachment lifecycle and interface interactions still require comprehensive regression testing.

---

7. API CONSOLIDATION ARCHITECTURE


The consolidated architecture can be represented as:

TXTWRK CENTRAL
│
├── Server Management
│ ├── Server registration
│ ├── Verification
│ ├── Stored credentials
│ └── Signed communication
│
├── Workspace Kit
│ ├── File management
│ ├── File editing
│ ├── File permissions
│ └── Checklist integration
│
├── Checklist Kit
│ ├── Items and groups
│ ├── Applications
│ ├── Comments and replies
│ ├── Threadlets
│ ├── Connected files
│ └── Member directories
│
├── Messaging Kit
│ ├── Personal identity
│ ├── Delegated identity
│ ├── Group/direct messaging
│ └── Server-backed media
│
├── Shared Authorisation
│ ├── Server ownership
│ ├── File Access
│ ├── Checklist membership
│ └── Messaging Access
│
└── Shared File Reference Management
├── Comment references
├── Reply references
└── Threadlet references
│
▼
CONNECTED SERVER
│
└── /TXTWRK.php
├── Files
├── Folders
├── Uploads
├── Downloads
├── Rename
├── Move
└── Delete

This represents the logical architecture visible in the reviewed code. It does not imply that every component has been consolidated into one physical PHP file.

---

8. FILE REFERENCE SYNCHRONISATION


One of the most important later developments was central attachment-reference synchronisation.

Purpose


When a file or directory changes location, TXTWRK must preserve the relationship between that file and the content referencing it.

Current Implementation


The reviewed function is:

txtwrkSyncConfirmedMoves()

It is designed to run after the Connected Server confirms a Rename or Move operation.

Database Tables


Checklist Comments


Table:

post_c_comment

Fields:
•file_connected_array
•thumbnail

Checklist Replies


Table:

checklist_reply_uploads

Field:
•file_location_name

Threadlets


Table:

threadlet_media_files

Fields:
•relative_path
•original_name

Server Isolation


Reference updates are scoped to the selected Connected Server.

This prevents an operation on one server from indiscriminately updating matching paths belonging to another server.

Example


Original attachment:

/opensource/system/checklists/user_i/files/photo.jpg

Renamed attachment:

/opensource/system/checklists/user_i/files/new-photo.jpg

After a confirmed Rename operation, the synchronisation function can update the relevant stored references.

Current Limitations


The reviewed implementation does not fully establish:
•Reference cleanup after Delete
•Synchronisation of Threadlet thumbnail_path
•Complete Messaging attachment synchronisation
•Automatic recovery from partial failures

Assessment


Status: Rename/Move synchronisation implemented for reviewed Checklist attachment structures.

Deletion and broader lifecycle consistency remain unfinished or unverified.

---

9. ORIGINAL CODE VERSUS CURRENT DEVELOPMENT


CapabilityOriginal FoundationDeveloped System
Directory APIGeneral filesystem operationsIntegrated Workspace and Checklist file management
Server APIConnect and verify serversShared Connected Server infrastructure
Messaging APIPrivate communication and mediaIntegrated storage authorisation
WorkspaceExisting file-management actionsConnected Server routing and Checklist integration
ChecklistItems, comments and repliesDirectories, richer media and Threadlets
AuthenticationSigned server requestsAdditional feature-specific permission checks
AttachmentsFeature-specific stored pathsCentral Rename/Move synchronisation
MediaExisting uploads and previewsExpanded thumbnail and video handling
Mobile UIExisting responsive controlsTargeted overlay and scrolling corrections
The original system already contained substantial functionality.

Later work should therefore be described primarily as consolidation, integration, extension and refinement rather than the creation of every capability from nothing.

---

10. SECURITY AND ACCESS CONTROL


The reviewed architecture includes several protection layers.

Connected Server Security

•Server verification
•Server ID checks
•Stored server secrets
•Signed requests
•Timestamp and nonce handling

Workspace Security

•Server ownership checks
•File Access permissions
•Allowed folders
•Allowed files
•Path validation

Checklist Security

•Checklist ID validation
•Server association
•Owner/participant checks
•Member directory restrictions

Messaging Security

•Messaging Access grants
•Delegated identity handling
•Group upload authorisation
•Direct-message upload authorisation
•Separation of identity and storage entitlement

Remaining Security Work

•End-to-end authorisation testing
•Cross-server isolation tests
•Path traversal testing
•Partial-operation recovery
•Destructive-operation permission checks
•Consistent error handling

Assessment


Status: Multiple security layers implemented.

A complete production security audit has not been established from the available files.

---

11. DEVELOPMENT PROGRESSION


Phase 1 — Original API Foundation


Established:
•Directory API
•Server API
•Messaging API
•Connected Server verification
•Remote filesystem communication

Phase 2 — Backend Consolidation


Developed:
•Shared Connected Server communication
•Signed operations
•Central server selection
•Permission routing
•Workspace compatibility

Phase 3 — Workspace Integration


Expanded:
•Remote file management
•File editing
•File locks
•Versions
•Archive operations
•Delegated File Access

Phase 4 — Checklist Integration


Developed:
•Checklist-selected Connected Servers
•Participant directories
•Connected file management
•Comment and reply attachments
•Directory viewers

Phase 5 — Collaboration Expansion


Refined:
•Threadlets
•Connected media
•Video thumbnails
•Web Impressions
•Nested discussion presentation

Phase 6 — Reference Synchronisation


Implemented:
•Comment attachment path updates
•Reply attachment path updates
•Threadlet attachment path updates
•Server-scoped Rename/Move synchronisation

Phase 7 — Interface Refinement


Addressed:
•Mobile Safari scrolling
•Overlay behaviour
•Apply Now navigation
•Dynamic viewers
•Threadlet layout
•Pagination interactions

Phase 8 — Current Consolidation Completion


Outstanding priorities:
•Safe deletion handling
•Thumbnail-path synchronisation
•Messaging reference verification
•Consistent operation results
•Cross-kit regression testing
•Security and failure-recovery testing

---

12. CURRENT DEVELOPMENT STATUS


SystemAssessment
Connected Server infrastructureImplemented
Server verificationImplemented
Signed API requestsImplemented
Directory API integrationImplemented
Workspace file operationsImplemented
Checklist directoriesImplemented
Checklist comments/repliesImplemented
ThreadletsImplemented
Media and thumbnailsImplemented with remaining path-consistency work
Messaging storage authorisationImplemented in gateway
Checklist Rename/Move reference syncImplemented
Delete reference protectionIncomplete or unverified
Threadlet thumbnail-path syncIncomplete
Complete Messaging attachment lifecycleNot fully verified
Cross-kit integration testingNot established
Production security auditNot established
These assessments refer to reviewed source code and reported testing, not measured percentages of completion.

---

13. REMAINING DEVELOPMENT PRIORITIES


Priority 1 — Attachment Deletion


Establish a consistent policy for deleting files still attached to comments, replies or Threadlets.

Recommended approach:

Block deletion while active references exist, unless an explicit attachment-removal workflow is used.

Priority 2 — Threadlet Thumbnails


Synchronise or invalidate thumbnail_path when the corresponding media is renamed or moved.

Priority 3 — Messaging Integration


Verify Messaging file-reference behaviour against the same lifecycle standards used for Checklist attachments.

Priority 4 — Shared API Responses


Standardise operation responses across controllers and the Connected Server.

Avoid forcing success = true when the remote operation has failed.

Priority 5 — Cross-Kit Testing


Test complete workflows involving multiple kits.

Example:

1. Upload a file through Checklist.
2. Attach it to a comment.
3. Open it through Workspace.
4. Rename it.
5. Confirm the comment still opens it.
6. Move its parent directory.
7. Confirm the reference updates.
8. Attempt deletion.
9. Verify the selected deletion policy is enforced.

Priority 6 — Stability


Preserve existing user interfaces and controls while strengthening the shared backend.

Avoid creating additional parallel APIs for operations already supported by the consolidated infrastructure.

---

14. FINAL ASSESSMENT


The original TXTWRK architecture began with:

DIRECTORY API KIT

The developed architecture now consists of:

TXTWRK CENTRAL

The central architectural achievement is that file storage, user identity, authorisation and collaboration records can remain separate while operating through common infrastructure.

Workspace manages files.

Checklist organises work and associates files with collaborative discussions.

Messaging provides private communication and authorised media storage.

The Server API establishes trusted communication with Connected Servers.

The Directory API supplies reusable filesystem operations.

The consolidation layer connects these responsibilities.

Overall Conclusion


TXTWRK has progressed substantially beyond its original three-kit foundation.

It now represents an integrated platform for connected storage, file management, collaborative Checklist work and Messaging.

The next development milestone is not another independent API Kit.

It is completing the consistency of the existing consolidated architecture across every file operation, permission boundary and attachment relationship.

The foundation is implemented. The remaining challenge is complete cross-kit reliability and verification.

---

REPORT SCOPE


This report is based on:
•Original API source files shared in the conversation
•Subsequent Workspace and Checklist implementations
•Connected Server gateway and runtime code
•Messaging-related gateway code
•Reference synchronisation functions
•Threadlet and media-related development
•Interface changes and reported testing

It does not constitute a live production audit, a complete line-by-line diff of every revision or confirmation that every generated replacement file has been deployed.

1/6
🗖 VIEW