New Plugin for “Druzh-Ok” Module –  MyMemoryMoments (MMM)

Addition – Plugin for

“Druzh-Ok”

that is, there is also Plus, you can Invite or Take as a friend of some type (secret friend, lover, husband, closed, arbitrary open information about relationships, etc., including options open information offered or closed, a lot options for every taste, since this is Elven Land and all the names and stories there are “invented and written down entirely from the fantasies of the Application users, which is true, since everyone writes what they know or simply made up from their personal Memory.

At the same time, this map and all descriptions of places can be seen only by those who are authorized in the Main Application of Elven Land.

Therefore, all those who use the application understand that they are “responsible” (since they are in the game-application) so that they are “responsible” for everything that the User describes about the history of the place. Moreover, the main goal is to show a person to the community, so to speak, to focus attention on information about the place, and the User himself wants this and gives this information openly. He can also indicate that he can give this information for “a certain fee” in the App for a certain number of Elvens. What is automated?

In this case, the Project provides, for example, a three-year “guarantee” or a five-year guarantee for information, blocking transfer for withdrawal during the required period. Or using other methods of “checking information for credibility. Including paid input, which should be reflected “outside”,

For example, I mark the address and write,

in this house

City,
ADDRESS, ahhh
card 23,
Floor, 5
view from the window,
photo from the balcony,
parking,
photo from 1987.

We met in 1989 with Name1 and Name2, who then worked as saleswomen at the market. We walked there all night, drank vodka, had a snack, then (^you can see when you will be Member of XXX Club, or trancfere some Elven Coins to User) …………we did…………..

And on this  Hiden information there is a Badge – Conditions to see Hiden MMM.

If you click on this Icon, you can see what this user wants to receive for this information, how much, what, but only through Our Application all payments, and you can do this: For Example

For 2 coins you can open and read the information once.
For 10 Coins you can open and read the information and always have access for life.
For 15 you can get everything + personal data – phone, email, country, city. and communication directly with our application in the messenger.

There may even be a place on Google map linked to the address.

• Of course, there may be free information, however, information that contains intimate details of a place is always paid, and everyone sets their own price for it.

In order to post information, you need to “sign” several conditions, which include information about secrets and so on.

However, all information that is entered and used by “Elven” is an internal game in the Elven Land Application and is an Element or Elements of the Game and has relation to the real world.

That is, in any case, we remain in the game, although everyone publishes information about the place and, most importantly, the time when this happened.

Another example.

A man goes to the map of his town, or the area where he lived twenty years ago,

sees

The dot is lit –

There is information (1987 February 12, 12-30, Lenin Street, view from the window of apartment 45 on the 4th floor)
there is an old photo, a road, holey asphalt, puddles full of water.

Can be included in the Chip Application,

If you now click on this link on the Info point with the date 1987, etc., then this exact time will open, and if you continue to look at the general map of Places, they will also be “filtered” and will show places of the same year and, if necessary, on this day and hour, types or descriptions of events of this year, hour, day, etc.HISTORY OF THE PLACE,

For example

Point  +

You Country, street, Images (if there are)

Example of explanation of this place:

The house belonged to my grandmother, Name, then my mother Name, who sold it, according to her, to an officer, after the death of her mother.

There was a house opposite.

The FamilyName lived there, they had a cow. As a child, I grew up in the summer on her delicious, sweet, fatty and very real Morning Steam, a little cooled down near the threshold, with milk, in a three-liter jar, where half the palm of my hand already had time to accumulate fresh cream, the taste of which is more amazing than the taste of ice cream.

What is the point of such an application?

There comes a time in every person’s life when they want to know something from the past, their past, but there are no such archives that could compete with collective memory.

And by adding or using this information about the place and the history associated with this place, we also help preserve the history of people.

 

Database Design for Elven Land Project’s “Druzh-Ok” Application

To support the functionalities described for the “Druzh-Ok” application, we need a comprehensive database design that includes user data, location-based information, historical entries, and transactional data for premium content. Here’s a detailed design proposal for the database:

#### 1. **Users Table**
Stores information about each user.

| Column Name | Data Type | Constraints |
|——————|——————|———————————|
| user_id | UUID | Primary Key |
| username | VARCHAR(50) | NOT NULL, UNIQUE |
| password_hash | VARCHAR(256) | NOT NULL |
| email | VARCHAR(100) | NOT NULL, UNIQUE |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP |
| last_login | TIMESTAMP | NULL |
| avatar_url | VARCHAR(256) | NULL |
| bio | TEXT | NULL |

#### 2. **Locations Table**
Stores information about specific locations mentioned by users.

| Column Name | Data Type | Constraints |
|——————|——————|———————————|
| location_id | UUID | Primary Key |
| user_id | UUID | Foreign Key -> Users(user_id) |
| name | VARCHAR(100) | NOT NULL |
| description | TEXT | NULL |
| address | VARCHAR(256) | NOT NULL |
| latitude | DECIMAL(10, 8) | NOT NULL |
| longitude | DECIMAL(11, 8) | NOT NULL |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP |

#### 3. **HistoricalEntries Table**
Stores historical or personal entries tied to locations.

| Column Name | Data Type | Constraints |
|——————|——————|———————————|
| entry_id | UUID | Primary Key |
| location_id | UUID | Foreign Key -> Locations(location_id) |
| user_id | UUID | Foreign Key -> Users(user_id) |
| title | VARCHAR(100) | NOT NULL |
| content | TEXT | NOT NULL |
| photo_url | VARCHAR(256) | NULL |
| date_of_event | DATE | NULL |
| is_premium | BOOLEAN | DEFAULT FALSE |
| price | DECIMAL(10, 2) | DEFAULT 0.00 |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP |

#### 4. **Friends Table**
Stores friendship relationships between users.

| Column Name | Data Type | Constraints |
|——————|——————|———————————|
| user_id | UUID | Foreign Key -> Users(user_id) |
| friend_id | UUID | Foreign Key -> Users(user_id) |
| relationship_type| VARCHAR(50) | NOT NULL |
| status | VARCHAR(20) | NOT NULL, DEFAULT ‘pending’ |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP |
| PRIMARY KEY (user_id, friend_id) | |

#### 5. **Transactions Table**
Stores information about transactions for premium content.

| Column Name | Data Type | Constraints |
|——————|——————|———————————|
| transaction_id | UUID | Primary Key |
| user_id | UUID | Foreign Key -> Users(user_id) |
| entry_id | UUID | Foreign Key -> HistoricalEntries(entry_id) |
| amount | DECIMAL(10, 2) | NOT NULL |
| transaction_type | VARCHAR(20) | NOT NULL |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP |

#### 6. **Messages Table**
Stores messages exchanged between users.

| Column Name | Data Type | Constraints |
|——————|——————|———————————|
| message_id | UUID | Primary Key |
| sender_id | UUID | Foreign Key -> Users(user_id) |
| receiver_id | UUID | Foreign Key -> Users(user_id) |
| content | TEXT | NOT NULL |
| is_read | BOOLEAN | DEFAULT FALSE |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP |

### Database Relationships

– **Users Table**: Central to all relationships.
– **Locations Table**: Linked to users and historical entries.
– **HistoricalEntries Table**: Linked to users and locations; includes premium content info.
– **Friends Table**: Manages friendship relationships with different types (e.g., secret friend, lover).
– **Transactions Table**: Tracks financial transactions for accessing premium content.
– **Messages Table**: Handles direct communication between users.

### Features and User Interactions

1. **User Registration and Authentication**: Managed by the Users table.
2. **Location-Based Information**: Managed by the Locations table.
3. **Historical Entries**: Managed by the HistoricalEntries table, with premium content options.
4. **Friendship Management**: Managed by the Friends table, allowing various types of relationships.
5. **Transactional Management**: Managed by the Transactions table, handling payments for premium content.
6. **Messaging System**: Managed by the Messages table for in-app communication.

### Implementation Notes

– Use UUIDs for unique identifiers to ensure scalability and uniqueness across distributed systems.
– Implement appropriate indexing on frequently queried columns to enhance performance.
– Ensure robust security measures for user data, including encryption for sensitive information like passwords.
– Integrate with payment gateways for handling transactions securely.
– Use geospatial indexing for efficient querying of location-based data.

A UUID is a 128-bit number used to uniquely identify information in computer systems. UUIDs are designed to be globally unique. The most common format for a UUID is a string of 32 hexadecimal digits, displayed in five groups separated by hyphens.

Why Use UUIDs?

1. Global Uniqueness:
   • UUIDs are generated in such a way that they are unique across different systems and databases without requiring a central authority to manage their uniqueness.
   • This makes them suitable for distributed systems where unique identification across multiple databases or systems is needed.
2. Decoupling from Database Logic:
   • Using UUIDs decouples the identifier generation from the database, allowing for easier migration, replication, and integration of databases.
3. Scalability:
   • UUIDs are beneficial in scenarios where databases are sharded or distributed across multiple nodes, as they ensure that each node can generate unique identifiers independently.
4. Security and Obfuscation:
   • UUIDs are not sequential, making it harder for malicious users to guess the number of records or the pattern of record creation, providing an additional layer of security.

This design ensures that the “Druzh-Ok” application can effectively manage user interactions, historical data, and premium content transactions within the magical and immersive context of Elven Land.

 

0 More Elven Likes