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: 26 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: Messaging
⛶
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'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 — 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 Development Report

Audio Across Posts, Checklists & Messaging

16 September 2026


Today marked a significant expansion of audio communication across TXTWRK.

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

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

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

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

---

1. Audio Rooms in Posts


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

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

Room Status


A newly created Audio Room begins Offline.

The room owner can switch it between:
•Offline
•Live

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

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

Guest Participation


Visitors can request to join an Audio Room.

The room owner receives a participation log and can manage requests by:
•Accepting a participant
•Removing acceptance
•Blocking a participant
•Viewing all requests
•Viewing blocked users
•Unblocking users

Accepted participants are then permitted to record within the room.

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

Recording Limits


The host has unrestricted recording time.

Guest recording limits can be configured using options including:
•10 seconds
•15 seconds
•30 seconds
•1 minute
•3 minutes
•Unlimited

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

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

Dynamic Room Behaviour


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

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

Once accepted, recording functionality becomes available to them.

Recording and Playback


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

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

Data Accounting


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

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

Post Audio Room Structure


Conceptually:

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

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

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

---

2. Audio Rooms in Checklists


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

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

It represents structured work, collaboration and existing permissions.

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

Audio Attached to a Checklist Item


A Checklist Audio Room belongs directly to a checklist item.

Conceptually:

Checklist
└── Checklist Item
└── Audio Room

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

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

Turning Audio On


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

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

They can be activated where audio collaboration is useful.

Checklist Permissions


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

Therefore the Post Audio Room workflow of:

Join
↓
Request
↓
Host Accepts
↓
Recording Enabled

is unnecessary.

Instead:

Checklist Permission
↓
Audio Room Permission

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

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

Recording Topics


Checklist recordings can optionally be associated with topics.

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

Recordings can subsequently be filtered according to the selected topic.

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

Date Organisation


Recordings can be grouped and retrieved by date.

Features such as:
•Play Today
•Date grouping
•Initial recording limits
•View More loading

allow longer-running checklist discussions to remain manageable.

Live Behaviour


Checklist Audio Rooms can still operate with Live behaviour.

Polling can be limited to situations where:
•the Audio Room is Live; and
•the room is currently within the user's viewport.

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

---

3. Checklist Audio Storage


Checklist Audio Rooms introduced another important capability: selectable storage.

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

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

TXTWRK Storage


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

Connected Server Storage


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

Conceptually:

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

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

This begins separating two concepts:

the network managing the collaboration

from:

the infrastructure storing the media

---

4. Public Checklist Listening


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

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

The distinction becomes:

Listening
│
└── Can be public where enabled

Recording
│
└── Requires appropriate checklist access

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

---

5. Audio Chats in Messaging


The third major development brought recorded audio into TXTWRK Messaging.

Audio Chats are being integrated into both:
•Direct conversations
•Group conversations

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

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

Messaging Composer


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

Conceptually:

🎙️ 🔗 Message... Send

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

Recording


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

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

Audio Without Text


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

A message can therefore consist entirely of:

🎙️ Audio Recording

rather than requiring:

Text + Audio Recording

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

Direct Conversations


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

Group Conversations


The same capability is available within group messaging.

The messaging architecture therefore becomes:

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

---

6. Messaging Audio Storage


Messaging Audio Chats also introduce selectable storage.

The default storage destination is TXTWRK Data Balance.

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

Default


Audio Storage:
TXTWRK Data Balance

This requires no additional server configuration.

Connected Server


Where suitable infrastructure has been configured:

Audio Storage:
My Messaging API Server

can be selected instead.

Conceptually:

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

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

---

7. TXTWRK Messaging Audio Storage Structure


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

Its storage hierarchy is:

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

group/
{group_id}/
audio_xxxxx.webm

This keeps:
•Post Audio Rooms
•Checklist Audio Rooms
•Messaging Audio Chats

separate at the storage level.

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

---

8. Messaging Audio Data Accounting


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

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

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

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

---

9. Audio Deletion and Ownership


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

TXTWRK-Hosted Audio


Where TXTWRK owns the physical stored object, the system can manage:
•physical deletion;
•storage metadata;
•data accounting; and
•appropriate data refunds.

User-Server Audio


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

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

Conceptually:

TXTWRK-hosted recording
↓
TXTWRK controls storage lifecycle

User-server recording
↓
Server owner controls storage lifecycle

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

---

10. Protecting Private Messaging Audio


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

The directory:

/1-audio-rooms-messaging/

can have its own .htaccess protection.

The protection includes:
•directory indexing disabled;
•executable scripts blocked;
•unexpected file types blocked;
•MIME sniffing protection;
•direct/no-referrer requests rejected; and
•playback requests restricted to TXTWRK-originating pages under the current hotlink-protection model.

This protection applies only to Messaging Audio.

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

---

11. End-of-Day Audio Architecture


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

AreaAudio TypePrimary PurposeParticipationStorage
PostsAudio RoomsSocial discussionHost + requested/accepted guestsTXTWRK
ChecklistsAudio RoomsWork collaborationChecklist-authorized usersTXTWRK or connected server
MessagingAudio ChatsPrivate communicationDirect/group participantsTXTWRK or Messaging API server
This separation is important.

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

Each implementation reflects its environment.

---

12. Social Audio


Post Audio Rooms represent the social layer.

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

The conversation revolves around published content.

---

13. Work Audio


Checklist Audio Rooms represent the work layer.

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

The conversation revolves around a specific piece of work.

---

14. Private Audio


Messaging Audio Chats represent the private communication layer.

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

The conversation revolves around private communication between users or groups.

---

15. One Audio Layer Across TXTWRK


Together, the three implementations can be viewed as:

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

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

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

---

16. Competitive Comparison — TXTWRK Audio Across the Network


Recorded audio itself is not unusual among modern communication networks.

Major messaging and collaboration platforms already provide various forms of:
•voice messages;
•recorded clips;
•voice channels;
•calls;
•meetings; and
•synchronous audio.

The more relevant comparison is therefore not:

"Does TXTWRK have audio?"

The more useful question is:

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

That produces a considerably more interesting comparison.

---

17. Comparison With Other Major Networks


CapabilityTXTWRKWhatsAppDiscordSignalSlackMicrosoft Teams
Recorded audio in direct messagingYesYesYesYesYesYes
Recorded audio in group messagingYesYesYesYesYesYes
Audio connected directly to social postsYesNo direct equivalentDifferent modelNoDifferent modelDifferent model
Dedicated Audio Room attached to a postYesNoVoice channels use a different modelNoHuddles use a different modelMeetings use a different model
Audio attached directly to checklist/work itemsYesNoNo direct equivalentNoNo direct equivalentNo direct equivalent
Existing checklist permissions control recording accessYes—————
Public listening with controlled recording participationYes—Different model—Different modelDifferent model
Choice between platform storage and user's own serverYesNo normal user-facing equivalentNo normal user-facing equivalentNo normal user-facing equivalentNo normal user-facing equivalentNo normal user-facing equivalent
Own-server audio can avoid platform data usageYes—————
Audio integrated across social + work + private messagingYesPrimarily messagingCommunity + messagingPrimarily messagingWork + messagingWork + messaging
The comparison is not intended to suggest that other platforms lack sophisticated audio systems.

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

The distinction is the combination TXTWRK is developing.

---

18. Comparison With Messaging Networks


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

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

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

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

A user can potentially choose between:

TXTWRK-hosted media

or:

User-hosted media

while continuing to use the same TXTWRK conversation.

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

---

19. Comparison With Community Platforms


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

Its ecosystem combines messaging with community-oriented voice functionality.

TXTWRK Post Audio Rooms approach community audio differently.

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

Conceptually:

Traditional Community Voice

Community
↓
Voice Channel
↓
Conversation


TXTWRK Post Audio

Post
↓
Audio Room
↓
Conversation about that Post

The content itself becomes the location of the audio discussion.

---

20. Comparison With Workplace Platforms


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

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

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

Instead of:

Channel
↓
Discussion
↓
User determines which task it concerns

TXTWRK can provide:

Checklist Item
↓
Audio Discussion
↓
Context already established

The recording is already attached to the object being discussed.

This reduces the separation between communication and the work itself.

---

21. Storage as an Architectural Difference


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

A conventional hosted network can broadly be represented as:

User
│
▼
Platform
│
▼
Platform-Controlled Storage

TXTWRK is developing another possibility:

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

TXTWRK can remain responsible for:
•identity;
•permissions;
•conversations;
•checklist relationships;
•room metadata;
•interfaces; and
•application logic

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

---

22. Data Balance or Infrastructure Ownership


This creates two different ways of consuming an audio service.

TXTWRK Data Balance


The simplest route is:

Record
↓
TXTWRK
↓
TXTWRK Storage
↓
Data Balance

No external infrastructure is required.

User Infrastructure


A user with their own compatible server can instead use:

Record
↓
TXTWRK
↓
Connected Server
↓
User-Controlled Storage

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

---

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


This is an important architectural principle emerging from the work.

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

Platform = Application + Communication + Storage

TXTWRK can increasingly operate as:

TXTWRK = Application + Communication + Coordination

while:

Storage = TXTWRK OR User Infrastructure

That distinction is now visible in both:
•Checklist Audio Rooms
•Messaging Audio Chats

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

---

24. Different Permission Models for Different Contexts


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

Post


A public/social Audio Room requires explicit moderation.

Visitor
↓
Join
↓
Host Accepts
↓
Record

Checklist


A collaborative work environment already knows who should have access.

Checklist User
↓
Existing Permission
↓
Record

Messaging


A private conversation already establishes participation.

Conversation Member
↓
Direct / Group Access
↓
Record and Send

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

---

25. Why This Is More Than a Microphone Button


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

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

It includes:
•room ownership;
•Live/Offline state;
•participation requests;
•acceptance;
•blocking;
•recording limits;
•checklist permissions;
•public listening;
•recording topics;
•filtering;
•date organisation;
•direct messaging;
•group messaging;
•audio-only messages;
•inline playback;
•TXTWRK storage;
•connected-server storage;
•data accounting;
•storage ownership;
•deletion behaviour; and
•protected private media directories.

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

---

26. TXTWRK's Emerging Audio Model


The architecture can now be summarised as:

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

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

---

27. Areas Where Established Platforms Remain More Mature


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

Depending on the platform, these include areas such as:
•native mobile recording experiences;
•end-to-end encrypted media delivery;
•transcription;
•captions;
•accessibility;
•noise processing;
•waveform interfaces;
•playback-speed controls;
•large-scale media delivery;
•synchronous calling;
•large voice channels;
•sophisticated notification systems; and
•extensive moderation infrastructure.

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

The significance is the combination and integration being developed.

---

28. TXTWRK's Combination


TXTWRK can increasingly be described as combining:

SOCIAL PUBLISHING

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

---

29. Today's Progress


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

The architecture now covers:

POSTS
│
▼
AUDIO ROOMS


CHECKLISTS
│
▼
AUDIO ROOMS


MESSAGING
│
▼
AUDIO CHATS

Each serves a different type of communication.

Posts provide social discussion.

Checklists provide work-related collaboration.

Messaging provides private conversation.

---

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


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

The architecture now supports the idea that audio can belong to:
•published content;
•a collaborative task;
•a direct conversation; or
•a group conversation.

At the same time, the infrastructure work introduces the principle that the media itself can potentially belong either to:
•TXTWRK storage; or
•infrastructure controlled by the user.

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

The day's work can therefore be summarised simply:

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

Not a bad day's work.

1/3
🗖 VIEW
⛶
Technology
Neutral
Web Impressions are becoming a bigger part of TXTWRK — and now we’re adding Stickers to the mix. ✨

You can already create a Web Impression directly from the TXTWRK post box and publish it as a post, with the Web Impression player bringing it to life on the homepage.

But we’ve been building Web Impressions to go much further than a single post.

You can add Web Impressions to Checklist Items, then use Checklist Comments to build on them and really tell a story.

Your Profile Cover can also become a Web Impression. You can choose:

1. All My Web Impressions — showcase your creations.
2. Post ID Web Impression — feature a specific post.
3. Web Impression Code — create something specifically for your cover.

And now: Web Impression Stickers.

We don't see a Sticker as just a little graphic attached to something.

A Sticker can say I support you. I connect with you. I get this. This made me feel something.

They can bring joy, humour, encouragement, personality and uplifting energy into conversations — while also becoming genuinely engaging, interactive pieces of the TXTWRK experience.

We've seen over the last decade how powerful visual expression can become across social networks. With Web Impression Stickers, we want to take that idea further by making the expression itself programmable and customisable.

This weekend, we'll begin rolling Stickers out across comments and subthreads.

Next week, we're aiming to start bringing them into messaging.

And there's another side to this that we're particularly excited about.

Over the last year, we've purposefully been building our own technology around Web Impressions to help people market, promote, explain, showcase and tell their stories in ways that aren't limited to a static image or a block of text.

Stickers extend that technology into something smaller, faster and more social.

For brands, that could mean custom interactive campaign stickers, launches, reactions and visual identities.

For communities, it could mean their own symbols, celebrations, inside jokes, support messages and ways of recognising each other.

For creators and individuals, it becomes another little canvas for expressing something that words alone don't quite capture.

Web Impressions made the web itself part of a TXTWRK post.

Web Impression Stickers make it part of the conversation.

And we're only just getting started.

— @TXTWRK


⛶
Technology
Neutral
We've just learnt that our file storage API's: Directory API for Checklists and our Messaging API kit provides even more depth for enterprises/communities. You can now split directory space via domains/subdomains, for e.g. on multiple domains or the same domain with subdomains. With our recent addition, you can also split messaging via the same server, so all messages are centralised, by granting access for TXTWRK pages via our server tool. It's the perfect kit for community!

See visually how it looks as an architect...

---------------------------->
Directory API for Checklists

User 1: @TXTWRK
txtwrk.com
(Dedicated API Kit)

User 2: @TXTWRKLifestyle
lifestyle.txtwrk.com
(Dedicated API Kit)

---------------------------->
Messaging API

User 1: @TXTWRK
txtwrk.com/messaging/txtwrk/xyz/xyz/
(Dedicated API Kit)

User 2: @TXTWRKLifestyle
txtwrk.com/messaging/txtwrk/xyz/xyz/
(Shared API Kit)

The smart part of keeping messaging together across your pages, you can do this, by splitting actual server lifestyle.txtwrk.com to the txtwrk.com server but grouping messaging by choice via the @TXTWRK account > Server > Plugin Server > Messaging File Sharing

We're going to make sure that we update checklists in the post box with even better guidance on how to connect a server for file storage space, to ensuring our Dev tab shows information about all of our kits, right up to showing even more information in the Server tab too that recently found itself there! -- The truth is that our platform and guidance has constantly been changing, labels in, labels out, cleaning of the platform for simplifying etc. Thanks for your patience, if you have any recommendations, feedback right back to us by any means, ideally via our post box, document your work, get XP for us!