docs: added technical design #3
156
technical-design-assets/technical-design.drawio
Normal file
1
technical-design-assets/technical-design.svg
Normal file
After (image error) Size: 3.4 MiB |
104
technical-design.md
Normal file
@ -0,0 +1,104 @@
|
||||
# Cellar Social Technical Design
|
||||
|
||||
## Description
|
||||
|
||||
Sellar Social is a platform where aficionados 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 on to events.
|
||||
y marked this conversation as resolved
Outdated
|
||||
|
||||
## Design
|
||||
|
||||
Cellar Cocial consists of the backend and frontend apps supported by the database and the relay.
|
||||
|
||||
All services will be deployed to the linux ([Ubuntu](https://ubuntu.com/)) server and traffic routing will be manged by [Nginx](https://nginx.org/). The entire server should be backed up daily.
|
||||
y marked this conversation as resolved
Outdated
b
commented
Backups will happen at the host level, right? Backups will happen at the host level, right?
y
commented
yes yes
|
||||
|
||||
Cellar Social will also use external service for media hosting to avoid inappropriate data.
|
||||
|
||||

|
||||
|
||||
`Client` - [frontend app](#frontend)
|
||||
y marked this conversation as resolved
Outdated
b
commented
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
y
commented
Makes sense Makes sense
|
||||
|
||||
`API` - [backend app](#backend)
|
||||
y marked this conversation as resolved
Outdated
b
commented
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
|
||||
|
||||
### Frontend
|
||||
|
||||
The frontend app (`Client`) 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:
|
||||
|
||||
- [TypeScript](https://www.typescriptlang.org/)
|
||||
- [React](https://react.dev/)
|
||||
- [Nostr Login](https://github.com/nostrband/nostr-login) (authentication)
|
||||
y marked this conversation as resolved
Outdated
b
commented
is it worth mentioning the NDK, or the library we'll implement? is it worth mentioning the NDK, or the library we'll implement?
y
commented
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.
|
||||
|
||||
HTTP requests to Cellar Social API should include Nostr signatures, so the backend app will be able validate it and provide the response.
|
||||
|
||||
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 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/)
|
||||
- [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.
|
||||
y marked this conversation as resolved
b
commented
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
|
||||
|
||||
### 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
|
||||
- Coffee
|
||||
- Sake
|
||||
- Spirits
|
||||
- Wine
|
||||
- Reviews
|
||||
- NostrEvents
|
||||
|
||||
Database has to be backed up daily.
|
||||
y marked this conversation as resolved
b
commented
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..
y
commented
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.
|
||||
|
||||
### Relay
|
||||
|
||||
[strfry](https://github.com/hoytech/strfry) (`APP Relay`) will be used for Nostr events.
|
||||
|
||||
Npub whitelisting has to be enabled for strict relay access.
|
||||
y marked this conversation as resolved
b
commented
maybe a description of how this will work - eg, a javascript function injection on the relay event listener, which calls 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
|
||||
|
||||
### Media Server
|
||||
|
||||
[nostr.build](https://nostr.build/) will be used as a media server. It is used to avoid inappropriate data while media uploads.
|
||||
y marked this conversation as resolved
b
commented
used because of their excellent service and safety protections. Users can make use of their existing nostr.build subscriptions when they upload content. 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/
|
sign UP to in-person events