Structure, design and overall architecture thread

[Southclaws]

(A thread to throw early discussions about the design decisions etc)

General design:

• API-first
• OpenAPI spec
• Frontend optional - bring your own frontend/app
• Idiomatic Go where possible, but we're using dependency injection and some other useful tools
• Ent for database
• Focus on integration tests in the service layer
• Focus on very good seed data for testing/demos

Security:

• Cookies
• no JWTs except for super short-lived tokens
• API bearer tokens? Personal access tokens for admins?

Roles:

• Copy Discord's approach
• Roles have names+permissions+colours
• RBAC checked at service layer (Ent has this feature but the DB feels like the wrong place for it)

Bots:

• Bots can receive events and post content
• Same RBAC as users

Plugins and extensibility:

• WASM and AssemblyScript, Go, Rust, etc.
• Gotta finish the wazero runtime experiment
• Preferably no cgo
• Also API can be used to build plugins
• Marketplace? WAPM.io?

Deployment:

• Docker for simplicity
• Single static binary for non-Docker users
• Not sure how to do frontend for this though
• Frontend cannot be embedded as it's a Next.js app and requires SSR

Frontend:

• As accessible as possible (existing forums suck at this)
• Progressively enhanced
• fallbacks for all basic functionality
• Should work without JS for fundamental use-cases (posting, reading, etc)
• Next.js + Chakra and Vercel-friendly deploy

[Southclaws]

Auth:

• Ready for WebAuthn and FIDO
• Web3 login (Metamask, etc...)

Built a small PoC for WebAuthn and Metamask shouldn't be too hard. I'm considering removing the email address field from the account model so we're not forever bound to this ancient medium. I can see a world where people would want to run a forum which is entirely based on web3 auth and has no relationship to emails. Same for WebAuthn or any other social login.

I think doubling down on web3 logins and web3 profile pictures/eth domains is also a solid move to get some early traction.

Currently it's just password based login but eventually these systems will be configurable so you can disable and enable whichever auth method you desire.

[Southclaws]

Also a note regarding frontend type generation: the current codegen literally only generates types and nothing else. There's no swr or fetcher implementation. Orval seems the best bet but it's currently broken so I'm probably just going to write the barebones parts using the SSR API boilerplates from open.mp's frontend.

[ADRFranklin]

I assume you are leaving it up to the Auth providers to contain the unique identifiers, which explains why you removed the email address.

The problem now is how do you contact the user for resetting accounts? I'm not that familiar with web3 auth in particular, but we generally like multiple ways to recover an account, of course stuff like 2fa exists and along with that recovery codes, but some people may not like 2fa and want some other approach, so what are the plans to accommodate such systems?

Also what are the plans in the future for integrating custom authentication systems like some business may want, especially if they already have their own working systems?

[Southclaws]

Yeah I think there's definitely a challenge around modelling these concepts here. I feel like authentication and sending notifications are going to be tied in some way.

web3 accounts basically cannot be "reset" or at least it must be done on a case-by-case basis by the site admin. But if someone loses access to their wallet, that's their fault (that's basically how the web3 world works, there's no room for mistakes and no support teams to help you if you accidentally lose your private key etc)

But at the same time, I think users may welcome a service that doesn't need to contact them. Notifications can be done via native browser notifications or Discord/Slack integrations.

2fa is something that will apply only to Email, Password and OAuth authentication mechanisms. It won't apply to web3 or webauthn (I think)

[Southclaws]

Some more ideas around facilitating platforms that want to do some more out of the box things that you may argue push the boundaries of a "forum" for communities and move closer to a generic CMS... but still, these are fairly easy to build with the current architecture:

• Add a media URL/ID to the post schema so thread starters can be images, videos or audio (or any form of file really, it could be an IPFS link or an NFT - the frontend decides what to do with the URL/URI based on the scheme)
• Events, now this is likely a huge piece of work and I would put this off for a long time post MVP. But a lot of community driven platforms are centered around events, whether they are in-person or online. Discord did this already, there's Luma, Meetup and many more. It only makes sense to either provide integrations or a direct implementation (or both!)
• Wiki/knowledgebase/documentation is another selling point for a lot of software out there, but it's usually standalone. One issue we ran into with open.mp was we wanted our docs to share the same domain as our main site and forum. Because of this, we had to either do some hacky HTTP rewrites or just build everything in-house. It would make sense to provide a basic knowledgebase feature where authenticated users (with adequate permissions) can edit (or submit proposals) to simple Markdown documents arranged in a wiki-like structure. Think Docusaurus or Gitbook but less focus on tech and more on just general wiki-style content.