X

TXTWRK


PERSONAL
LinkingLinking
FollowingFollowing
ConnectionsConnections
MessagesMessages
NotificationsNotifications
DISCOVER
SearchSearch
ReelsReels
CalendarCalendar
MapMaps
Work
NotesNotes
NeedsNeeds
ContributionsContributions
TimetableTimetable
IntelIntel
To DosTo Dos
ChecklistsChecklists
SavesSaves
ScrapboardScrapboard
LinksLinks
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
Profile Image
Login

My Addresses

×
Addresses
+
Character Profiles
+
Info & Cover
+
Timetables
+
Favorited by... X
Link Clicks X
All comments... X
More | 1/33

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: 50 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...
DOUBLE TAP TO 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
•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: Technology
⛶
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
🚨📅 TikTok isn’t showing clear post publication dates — so we’re stepping away! 📱⏸️

👀 TikTok, there’s something you need to fix!

📅 Every post should clearly display the date it was originally published.

📰 Old news can look like breaking news.

🔄 Outdated content can resurface without context.

🤔 Users shouldn’t have to investigate when something was posted.

✅ Clear publication dates help everyone understand what they’re watching.

💡 A simple date makes a big difference!

👋 So, @TXTWRK is taking a break from TikTok until this issue is addressed.

🚫 No drama.

😌 No hard feelings.

📅 Just asking for clear, visible publication dates on every post.

💬 TikTok, sort out your timestamps and we’ll see you again! 👀✨

🌍 Until then, we’ll continue sharing our content elsewhere.

🤔 Do you find it frustrating when you can’t tell when a video was originally posted?

💬 Share your thoughts in the comments.

🔄 Repost if you think publication dates should be clearly visible.

📢 Let’s see how many people feel the same way!

💙 @TXTWRK

#TXTWRK #TikTok #ShowTheDate #DigitalTransparency #ContentAccountability

🗖 VIEW

⛶
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
⛶
Technology
Neutral
📢 TXTWRK Update: Introducing the Post Draft Upgrade with Library 💾


Create now. Save locally. Publish when you're ready.

At @TXTWRK, we're continuing to improve how people create, manage and publish content.

Our new Post Draft Library gives members greater control over unfinished posts, including posts containing text, images, videos, audio, checklists and other interactive content.

Instead of requiring every unfinished post to be uploaded to our servers, TXTWRK now supports browser-based draft storage.

You decide when to save, what to keep and when to publish.

---

💾 1. How the New Draft Library Works


TXTWRK uses your browser's IndexedDB storage system to save unfinished post payloads on your device.

A post payload is the collection of information you have entered or attached to a post before publication.

This can include your written content, selected options, attachments and other post settings.

FeatureWhat it does
💾 Save DraftManually save the post you're creating
📄 Manage DraftsBrowse previously saved post payloads
✏️ Update DraftMake changes and save over an existing draft
📑 Save New CopyKeep another version of your post
📂 Open DraftReturn saved content to the post composer
🔎 Search & FilterFind drafts by name, age or media content
🏷️ RenameGive saved drafts meaningful names
🗑️ DeleteRemove individual or multiple saved drafts
↺ Reset PostClear your current post without deleting saved drafts
There is no automatic draft saving.

When you press Save Draft, TXTWRK saves your current work locally. Changes made after that save must be saved again if you want to preserve them.

Your saved drafts remain available for later use, provided your browser retains its site storage.

---

🎬 2. More Than Just Saving Text


TXTWRK posts can contain considerably more than a message and a photograph.

Our draft system is designed to preserve the information entered across the post composer.

Supported content and settings


Post featureDraft support
📝 Text, topics and assetsSaved form content
📸 PhotosSelected files and preview restoration
🎥 VideosSelected video files and related fields
🎙️ Voice and MP3Audio files and form settings
🎚️ Audio StudioProject arrangements and recorded takes
📖 StoriesScenes, media and narration fields
ChecklistsItems, groups and selected settings
🖥️ Checklist ServersSelected server information
🛍️ ProductsProduct form values
📈 InvestmentsFunding details and settings
EventsEvent details and dates
❓ QuestionnairesSaved input values
📍 LocationsLocation IDs and form selections
🔒 PrivacyAudience and visibility choices
💰 Paid ContentPricing and subscription settings
📊 CSV and 3DSupported files and related form values
🌐 Web ImpressionsSaved fields and HTML content
Important: Basic form values are broadly supported. Some advanced interactive editors may require additional review or adjustment after reopening a draft. Not every generated preview or editor state is guaranteed to be restored perfectly.

Our aim is to make returning to complex unfinished posts much easier.

---

👥 3. What Happens When Multiple Members Use the Same Device?


TXTWRK links each local draft library to the signed-in member's unique memberID.

For example, imagine two TXTWRK members using the same computer and browser profile.

ActionMember AMember B
Signs into TXTWRKMember A active—
Saves three drafts3 local drafts—
Signs outDrafts remain stored—
Member B signs inA's drafts not listedB's library opens
Member B saves two drafts3 drafts remain2 local drafts
Member A signs back inOriginal 3 drafts appearB's drafts remain separate
### What does that mean?
•Each member gets their own draft list within the TXTWRK interface.
•Signing out does not automatically erase saved drafts.
•Returning to the same account, browser and device allows that member to reopen their drafts.
•Another member signing in is not shown the previous member's draft library.

A privacy reminder: Member-specific draft lists provide application-level separation, not encryption or complete protection from someone who has access to the device's browser storage. Avoid storing sensitive drafts on shared or public computers.

---

📱 4. What Happens If You Change Devices?


Because TXTWRK's new draft system is browser-based, the location of your drafts matters.

SituationWill your saved drafts be available?
Close and reopen the same browserUsually yes
Restart your phone or computerUsually yes
Return after switching between appsUsually yes
Sign out and back into the same accountYes, if local storage remains
Another member signs in on the same browserOnly their own drafts are listed
Use a different browserNo automatic transfer
Sign in on another phoneNo automatic transfer
Clear TXTWRK browser site storageDrafts may be permanently lost
Uninstall a browser or clear its app dataDrafts may be lost
Your TXTWRK account identifies which local draft library to display, but the files themselves are not synchronised between your devices.

Save Draft is not a cloud-backup service. Browser storage may be cleared or evicted, and large media files are subject to available storage capacity.

---

🌍 5. How Does TXTWRK Compare with Other Social Networks?


Different networks take different approaches to unfinished content.

PlatformDraft approachKey distinction
TXTWRKManual, browser-based Draft LibraryMultiple named post payloads with supported files and settings
InstagramDrafts for posts and ReelsPrimarily device-based editing and content drafts
TikTokVideo draft collectionDrafts are device-dependent and may be lost after app removal
XPost and thread draftsDraft behaviour varies by application and device
LinkedInPost and article draftsSome drafts can be continued across devices
FacebookPersonal and Page draft workflowsDraft management differs between personal posting and Pages
TXTWRK's focus is on preserving more of the post creation process, rather than treating a draft as written text alone.

We also recognise that other platforms offer features such as cross-device drafts that TXTWRK's local-only library does not currently provide.

This is a different approach, designed around user-controlled local saving and the wide range of content TXTWRK supports.

---

💽 6. Why Use Browser Storage Instead of Uploading Every Draft?


There are several benefits to keeping unfinished post payloads locally.

For members

•More control: Decide exactly when to save.
•Less unnecessary uploading: Saving a draft does not submit the post payload to TXTWRK's draft servers.
•Multiple projects: Keep several unfinished posts and return to them individually.
•Media recovery: Selected files can be stored locally when browser storage permits.
•Draft management: Organise older work without publishing or deleting everything.

For the platform

•Fewer unnecessary draft-storage requests.
•Less server storage consumed by unfinished post uploads.
•Reduced dependence on repeated server-side draft saving.
•Separation between preparing content and publishing content.

The distinction matters: saving locally prepares your work for later, while pressing Post sends your finished content through TXTWRK's normal publishing process.

---

🚀 7. How to Save and Reopen a Post


Using the Draft Library is straightforward.

1. Start creating a post. Add your text, media and other content.
2. Press 💾 Save Draft. Give your draft a name.
3. Continue working or leave TXTWRK. Your saved version remains in browser storage.
4. Return to TXTWRK. Sign into the same account using the same browser profile.
5. Press 📄 Manage Drafts. Browse or search your saved posts.
6. Select Open. TXTWRK loads the saved payload back into the composer.
7. Review and publish. Check restored media and settings, make any final changes, then press Post.

You can also use Save New Copy to preserve an earlier version while continuing to develop another.

What about old drafts?


The manager supports searching, sorting, filtering by age or media, and deleting individual or multiple saved records.

Saved drafts are not automatically removed simply because you reset the composer or publish a post. You can manage or delete those saved copies yourself.

---

⚠️ 8. Important Things to Remember


We want members to understand both the capabilities and limitations of this feature.

1. Browser storage is not unlimited. Large videos and other attachments may reach browser storage limits.

2. Save important work regularly. TXTWRK does not automatically save changes between manual saves.

3. Do not clear your site storage if you need your drafts. Clearing browser data can permanently remove locally saved content.

4. Use the same browser profile. Signing into TXTWRK on another browser or device will not automatically retrieve these drafts.

5. Review complex posts before publishing. Advanced media editors and interactive components may need adjustment after reopening.

6. Wait for a successful save confirmation. If saving fails because storage is full or unavailable, your latest changes have not been safely preserved.

---

🌱 9. What's Next for TXTWRK?


The Draft Library is another step towards making TXTWRK a more flexible environment for creating content.

We're building beyond the idea that a social post must be completed and published in one session.

Our longer-term goal is a creative environment where members can prepare detailed posts, work with different media formats, return to unfinished projects and manage their content before it goes public.

That means continuing to improve advanced editor restoration, media handling and the reliability of local draft recovery.

---

💬 Your Work. Your Timing. Your TXTWRK.


Not every idea needs to be published immediately.

Sometimes you want to write today, add media tomorrow, review your settings later and publish when everything is ready.

TXTWRK's Post Draft Library gives you that flexibility — with manual saving, local storage and multiple draft management tools.

Sign into TXTWRK, open your post composer and explore 💾 Save Draft and 📄 Manage Drafts.

What other draft-management features would you like us to introduce?

@TXTWRK — Helping the world make text work in daily life.

#TXTWRK #TXTWRKUpdate #SocialMedia #Drafts #ContentCreation #DigitalCreativity #CreatorTools #BrowserStorage #WebDevelopment

🗖 VIEW
⛶
Technology
Neutral
@ImSunnyClaire — “Everywhere is our stage”… Welcome to the future of TXTWRK Web Impressions as Themes & Overlays, to Slideshows for Stage!

Video Thumbnail