
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.
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 lets 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 behavior design, writing whitepapers, technical writing, blogging, and 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 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 officially call 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 to sell that document at a certain price, and place a buy offer through the marketplace 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 described here.
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 authorization, 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.
In the first submission, sTeX’s goal was to directly store document content on-chain. This approach had some advantages especially in delegating authorization 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.
On its own sTeX doesn’t bind much with Stellar being a LaTeX cloud 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.
$17.0K

No other submissions.