High-level description

The product I am presenting is sTeX, a cloud-based LaTeX editor featuring a modern user interface, as well as a fast and efficient user experience that aims to replicate Google Docs’ one. At its core, the app will feature a decentralized marketplace for documents (including but not limited to sTeX’s) which is built upon the multisig safety of Stellar turrets.

Why sTeX?

LaTeX is a document preparation system that enables its users to write highly customizable and professional PDF documents. Rather than writing documents with formatted text, LaTeX let’s you write documents in plain text, and uses markup tagging to define how the document looks like.

For example, both I and tdep#4794 use LaTeX almost on a daily basis for a variety of tasks:

• taking notes
• product behaviour design
• writing whitepapers
• technical writing
• blogging
• working on financial instruments (for writing math)

Most LaTeX editors aren’t cloud-based and require you to install both the app and a TeX compiler as well, and the existing cloud-based LaTeX editors have room for improvement, especially in terms of user experience, interface, and sometimes speed (more on the competitors section in “additional information“). That is why I have decided to start working with tdep#4794 to build a brand-new modern LaTeX editor inspired by Google Docs.

The Marketplace

The sTeX app will implement a decentralized marketplace at its core. Users will be able to effortlessly bring sTeX’s documents on-chain and have full control over them (sTeX’s app won’t have any signing power on your on-chain documents).

Once a document is on-chain (as a stellar account), we can call officially call it it a non-fungible-token (despite not being an actual stellar asset, tdep#4794 will discuss this NFT implementation later on this section). These NFTs can then be traded on a turrets-powered decentralized marketplace. The current progress in the marketplace as well as in sTeX’s “document detach” API endpoints allow to:

• write a LaTeX document
• create that document on-chain
• place a sell offer through the marketplace (https://github.com/Xycloo/documents-marketplace-devenv/blob/main/target/trade.js#L184) to sell that document at a certain price
• place a buy offer through the marketplace (https://github.com/Xycloo/documents-marketplace-devenv/blob/main/target/trade.js#L94) to buy a document at its price

Thanks to the design of the tokenized documents, they can be edited by the owner, meaning that interesting features like proofed document management can be achieved through the marketplace, for instance, you can issue an agreement contract you wrote to other two interested parties and set that the super-majority (2/3) consensus must be reached to edit the contract (for example three signers with a weight of 10 each and a medium threshold of 20).

The market is non-custodial and decentralized, based on stellar turrets. Turrets were initially called Turing Signing Server since what they actually do is leverage multisig and let serverless workers sign a “contract’s“ transaction. This means that by using more than one turret which aren’t owned by the same entity we can achieve a certain degree of decentralization. We have chosen Turrets over Soroban for a couple of reasons:

• since we want to keep the document-as-account design, turrets seem like our only option given the limited access of soroban contracts to stellar “classic“ data.
• we don’t need the degree of decentralization that native contracts offer given the fairly simple nature of our “contract“
• it will probably be much cheaper to run the contract on Turrets rather than using a soroban contract (though that’s TBD depending on how soroban’s cost model works out)
• our contract is on its own concurrency-safe, thus it doesn’t need such model as https://github.com/heytdep/All-Things-Turrets/blob/main/commitments-tx/mini-docs.md.

Overall, by using Turrets we save time and resources since Stellar already provides all the features we need for this contract.

Lastly, we also mention a possibility for an in-app freelancing mechanism supported by the marketplace, but we won’t implement for now since it would require high community participation in voting for disputes, which is currently out of scope of our app’s simple and intuitive design.

Editor Features

• secure and tested authentication and authorisation
• real-time compiler (our editor will display changes in the pdf as you finish writing your sentences)
• basic features (create, edit, share, manage access)
• templates (in development)
• advanced auto-completion
• vs-code alike editor
• commenting (in development)
• multiple themes (in development)

These are the features that are currently present in our editor, but feel free to recommend any that you deem interesting or necessary which we haven’t or aren’t implementing.

How Stellar powers our app

In the first submission, sTeX’s goal was to directly store document content on-chain. This approach had some advantages especially in delegating authorisation to Stellar validators, and mostly by also allowing non-custodial users in our app. However, tests showed that the approach held important disadvantages in terms of speed and efficiency. That is why we opted to using native storage for sTeX’s API. This does not mean that we don’t use stellar anymore at our app’s core, as a matter of fact, all our infrastructure is made of ed25519 keypairs that are ready to become stellar accounts once sTeX’s users begin creating documents on chain or start interacting with the marketplace. When documents are on-chain, sTeX still enables to modify those documents re-using the code in sTeX’s “first version“ where every update corresponds to a stellar transaction. The only difference is that now users that are only interested in writing LaTeX documents in a fast and friendly environment can do so without suffering decreased speed for something they do not need, and those interested in editing their on-chain documents can do so in a completely non-custodial way by signing transactions as they update their documents.

The above only talks about the Stellar integration in the most “traditional“ part of our codebase (create, edit and share documents), the rest is completely reliant on both Horizon and Stellar (bridge to detach documents, bridge to reattach documents, the DeFi marketplace).

You can review part of our code here, but that’s just the marketplace’s prototype contract since we don’t want to make our API public (maybe yet). What we focus on is balancing and intersecting our “traditional“ codebase with our stellar-based one, and making sure that every interaction with Horizon is non-custodial on the user’s end.

How sTeX can help Stellar adoption from non-blockchain users

On its on sTeX doesn’t bind much with Stellar being a LaTeX could environment, but with the built-in marketplace users who have probably never interacted with Stellar can experience for the first time Stellar in terms of payments speed and ease of possibly making of their documents a source of income.

sTeX’s backend facilitates the process of onboarding on-chain users without storing secrets or adding our signers to the users’ accounts, allowing them to start interacting on-chain on their own and not only through our service.

We have made significant progress since the last SCF:

• we have a fully shaped product, that can already be used quite comfortably (even if there’s still work to do).
• the editor is almost complete.
• trade documents on a decentralized marketplace (still need to implement on the front-end)

And we plan to add other features like commenting and real-time collaboration, as well as platform upgrades like rewriting the backend in Rust for a more optimized and maintainable experience.

As the home of our Stellar projects and as “proof-of-commitment” to the network, Xycloo has also been doing some work on other projects like tmyxer (a native open-source Stellar coin mixer powered by zero-knowledge proofs). Additionally, our team is constantly experimenting and keeping up with the updates regarding Soroban.

Revenue Model

We plan on having paid subscriptions to our app, but haven’t yet decided the price of the tiers. The two most important tiers will be the free one, and a “passionate“ one which you can check out here. We are also considering a plan designed for larger entities (i.e schools and businesses) but have to sort out whether we would be able to provide significant advantage over the “passionate“ tier.

Market Research and Competitors

As already hinted, sTeX will have some competitors, and even big ones like overleaf, which has already a lot of users. But we focused on building sTeX with the most efficient UX in mind, and our closed beta program helps us understand that we are succeeding to do so, for instance, I have already switched to comfortably using sTeX after having used overleaf. Additionally, with the marketplace we separate sTeX from the competitors shaping it more like a whole environment instead than just an editor.