Zingurus Architecture

This is the architectural document for zingurus.com.

• Audit
• Discover
• Document
• Architect
• Implement

The ultimate goal is to create a more usable twitter that can run at low cost in the cloud using druid and 000 methodology. Unbounded by the complexities stacked up over time and censorship regulations plaguing the tech industry.

All open search entities related to zingurus will be prefixed with zingarus

I think we begin by modeling what we can and fill in gaps as we go.

Gaps either need to be generisized enough to me part of druid core, extensions, micro-frontends, or live as components, services, etc. dedicated to specific druid site living in shell app. Could also be a separate lib.

Zings are forever unless deleted before response.

twitter is really not much more than a forum. This architecture can probably be reused for a forum. A forum could be built first than down graded / stripped of features to a twitter derivative. Not really sure that is the direction to head. Sharing to much and making things to abstract can become a nightmare to manage. Especially when you start talking about building a hierarchy of parent-child sites.

A zing is typically a conversation about content published on the web to ridicule, make fun of or poke at. In a nutshell the only real purpose people still use sites like twitter these days.

Poc

The poc of this will be a minimum viable clone. Sacrifices will be made to achieve rapid development goals of a basic prototype that provides all fundamental features of twitter over usability / design. For example, instead of using models users might go to a different page instead to zing. I think this is fine for now especially if that page is nested on the current page and they can easily go back to the previous page once zing is posted.

Profiles

User profile including avatar and marketing mumbo jumbo.

Dashboard

Dashboard is the main home screen displayed upon login.

Panels

Left

Actions

Middle

Feed

Right

Blocks

• Search
• Trending
• Featured
• etc.
• aggregated list / tags

The blocks are nothing more than relevancy searches. This can be done using open search to aggregate data. For this type of data all of it can probably be stored inside open search. I don't think s3 is really needed here.

Compose Form Modal

Feature requirements and architectural break down of compose feature on twitter. Including modifications necessary to facilitate within context of druid ipe builder.

This doesn't necessarily need to be a modal. Although it would be nice to have druid support modals. I think it might be worth exploring further.

A modal is necessary to manage libraries. For example, to display emojis, gifs, etc. for selection to include in post. This can also pave the way to full fledge media library modal which would be really cool.

Message

Char limited input message.

Actions

Upload Media

Upload video, audio, images, docs (pdf) files.

This can be achieved with a new s3 crud adaptors for multipart data. The s3 client also supports Credential providers so zero trust can easy be used using standard s3 high level api for multipart uploads. Just need to build it.

Gif

Insert gif from media library of categories gifs. Possibly from external aggregated sources.

Poll

Embed poll / survey. View results and aggregate results.

Emoji

Insert emoji from emoji library.

Schedule

Schedule tweet in advance using date time.

This is just a matter of adding an optional date time to a post and using a open search filter.

Location ???

Geo forms field or location autocomplete like on locator prototype

Zing

• index: zingarus_zing

• entity: Zing

• templates:

  • main feed
  • user account feed
  • feed w/ filter options like specific tag could be merged with above.

• zing root

  • zing response
    • zing response
      • zing response
  • zing response

Comments

• Root comments
• Replies to comments in thread

Comments are just a hierarchy of zings or zings in response to a root level zing.

Respond - hierarchical model in open search.

Nested and repeating sections are not needed for a zing. Therefore, it is not critical to complete their data repopulation in druid forms before beginning work on this.

Notifications

• entity: Notification

Derived from a template query in open search.

sns? - can sns be queried for all users notifications easily or should they be replicated into open search for easily searching.

This might be extracted into an extension or separate micro front-end that can be used across multiple apps. The concept of a notification can be generic I think. Unless only interested in mentions derived from zing. hmm...

Mentions

• entity: Mention

Derived from a template query in open search.

search query

Account was mentioned in a zing @accountname

Find all zings that include @accountname as a word.

Tags / Categorization

• entity: Tag

#tagname

Derived from a template query.

Find all zings that include #tag as a word.

Follow

Need to easily run search of recent zings ranking all followers to top followed by most active, popular.

Advertising

Zings can be intermixed with advertising.