docs: added technical design #3

Merged
y merged 4 commits from technical-design into main 2025-03-24 07:51:38 +00:00
3 changed files with 301 additions and 0 deletions

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

After

(image error) Size: 3.5 MiB

116
technical-design.md Normal file

@ -0,0 +1,116 @@
# Cellar Social Technical Design
## Description
Cellar Social is a platform where admirers of international wine, sake, spirits and coffee can review, discuss, and order it.
## Key Features
Cellar Social will provide the following capabilities:
- Login using Nostr identity.
- View products.
- Leave product review.
- Evaluate multiple properties of the product.
- Provide a description.
- Upload media files.
- View product review.
- Leave a comment.
- Zap a review or a comment.
- Visit the product producer page.
- Leave a comment.
- Zap a producer or a comment.
- Order the product.
- Engage with product related community.
- Provide NIP-05 names.
- View and sign up to in-person events.
y marked this conversation as resolved Outdated
Outdated
Review

sign UP to in-person events

sign UP to in-person events
## Design
Cellar Social consists of the backend and frontend apps supported by the database and the relay.
All hosted services will be containerised and deployed to the linux ([Ubuntu](https://ubuntu.com/)) server and traffic routing will be managed by [Nginx](https://nginx.org/). The entire server should be backed up (at the host level) daily.
y marked this conversation as resolved Outdated
Outdated
Review

Backups will happen at the host level, right?

Backups will happen at the host level, right?
Outdated
Review

yes

yes
Cellar Social will also use an external service ([nostr.build](http://nostr.build/)) for media hosting to avoid inappropriate data.
![Alt text](./technical-design-assets/technical-design.svg)
Website - [frontend app](#frontend)
y marked this conversation as resolved Outdated
Outdated
Review

Might be better to rename this as the "Website" given that there are multiple (including non-hosted) frontend components

Might be better to rename this as the "Website" given that there are multiple (including non-hosted) frontend components
Outdated
Review

Makes sense

Makes sense
`API` - [API app](#api-app)
y marked this conversation as resolved Outdated
Outdated
Review

Perhaps rename this as "API"? Or keep as "backend" and include both API and the DB.

Perhaps rename this as "API"? Or keep as "backend" and include both API and the DB.
`DB` - [database](#database)
`APP Relay` - [relay](#relay)
`Media Server` - [media server](#media-server)
`NIP-05` - NIP-05 name register
`Npub Whitelist` - collection of whitelisted Npubs
`Nostr Communication Platform` - flotilla.social is planned to be used as a communication platform over Nostr
`Shopstr Marketplace` - shopstr.store is planned to be used as a Nostr marketplace
### Frontend
The frontend app (`Website`) is a web application that users will be able to use by visiting a URL via browser (browsers list is not defined at the moment). The app will be built using the following technologies:
y marked this conversation as resolved Outdated
Outdated
Review

is it worth mentioning the NDK, or the library we'll implement?

is it worth mentioning the NDK, or the library we'll implement?
Outdated
Review

potentially we'll use not just NDK, but nostr-tools or applesouce too. I would say it is more implementation details.

potentially we'll use not just NDK, but nostr-tools or applesouce too. I would say it is more implementation details.
- [TypeScript](https://www.typescriptlang.org/)
y marked this conversation as resolved
Review

mention NIP-98

mention NIP-98
- [React](https://react.dev/)
- [Nostr Login](https://github.com/nostrband/nostr-login) (authentication)
HTTP requests to Cellar Social API should include Nostr signatures to conform to [NIP-98](https://github.com/nostr-protocol/nips/blob/master/98.md). The `API` app will be able to validate and authorize requests based on `Authorization` header.
Frontend app will use websocket connections to the `APP Relay` to read/write appropriate data.
Frontend app should let users register [NIP-05](https://github.com/nostr-protocol/nips/blob/master/05.md) names and manage users' metadata.
### Backend
The backend includes API app and Database.
#### API App
The backend app (`API`) is a RESTful API that can be used via HTTP requests. It will be built using the following technologies:
- [TypeScript](https://www.typescriptlang.org/)
y marked this conversation as resolved
Review

will also provide an npub verification service for the whitelisting function on the relay

will also provide an npub verification service for the whitelisting function on the relay
- [Node.js](https://nodejs.org/en)
- [Express.js](https://expressjs.com/)
HTTP requests to the backend app should include Nostr signatures, so the app will be able to validate it and provide the response.
The backend app will have access to the database and will perform CRUD (create/read/update/delete) operations.
The backend app will also manage Npub whitelisting that `APP Relay` will use.
#### Database
[Cassandra](https://cassandra.apache.org/_/index.html) will be used as a NoSQL database (`DB`) to persist business data. Only the backend app will have access to the database.
The following tables are planned in the database:
- Users
y marked this conversation as resolved
Review

is this separate to the box backup? If so, how will we manage the backups..

is this separate to the box backup? If so, how will we manage the backups..
Review

You are right, we don't need to back the DB up separately unless a more frequent DB backup is required.

You are right, we don't need to back the DB up separately unless a more frequent DB backup is required.
- Coffee
- Sake
- Spirits
- Wine
- Reviews
- NostrEvents
y marked this conversation as resolved
Review

maybe a description of how this will work - eg, a javascript function injection on the relay event listener, which calls GET /user/verify/$npub or sth like that

maybe a description of how this will work - eg, a javascript function injection on the relay event listener, which calls `GET /user/verify/$npub` or sth like that
Database will be backed up daily during daily server backup.
### Relay
y marked this conversation as resolved
Review

used because of their excellent service and safety protections. Users can make use of their existing nostr.build subscriptions when they upload content.

link: https://nostr.build/features/

used because of their excellent service and safety protections. Users can make use of their existing nostr.build subscriptions when they upload content. link: https://nostr.build/features/
[strfry](https://github.com/hoytech/strfry) (`APP Relay`) will be used for Nostr events.
Npub whitelisting has to be enabled for strict relay access. An example of JavaScript function that can be used for whitelisting can be found here.
`APP Relay` will be available for communication at flotilla.social (users' npubs will be taken into account).
Multiple Shopstr instances will use the `APP Relay` to read and write data. Each Shopstr instance will have a dedicated subdomain at Cellar Social.
### Media Server
[nostr.build](https://nostr.build/) will be used as a media server. It is used because of their excellent service and safety protections. Users can make use of their existing nostr.build subscriptions when they upload content. More info can be found [here](https://nostr.build/features/).