docs: added technical design #3
184
technical-design-assets/technical-design.drawio
Normal file
1
technical-design-assets/technical-design.svg
Normal file
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
|
||||
|
||||
## 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
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 an external service ([nostr.build](http://nostr.build/)) for media hosting to avoid inappropriate data.
|
||||
|
||||

|
||||
|
||||
Website - [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` - [API app](#api-app)
|
||||
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
|
||||
|
||||
`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
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.
|
||||
|
||||
- [TypeScript](https://www.typescriptlang.org/)
|
||||
- [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
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
|
||||
- [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
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.
|
||||
- Coffee
|
||||
- Sake
|
||||
- Spirits
|
||||
- Wine
|
||||
- Reviews
|
||||
- NostrEvents
|
||||
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
|
||||
|
||||
Database will be backed up daily during daily server backup.
|
||||
|
||||
### Relay
|
||||
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/
|
||||
|
||||
[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/).
|
sign UP to in-person events