deso-protocol / dips

DeSo Improvement Proposals for improving the DeSo network

DeSo Improvement Proposals (DIPs)

Context

DeSo is a decentralized social network. All of the code and data are totally open and anyone can build on the network or contribute code to improve it.

The DIPs repo allows developers to submit proposals for major features to get feedback and buy-in from the community prior to submitting code for review.

DeSo is not a company, and it doesn't have a board or CEO. Instead, it has a committed developer community that collaborates via this repo.

Determining What to Work On

If you would like to contribute to DeSo, we have several kanban boards that contain ordered lists of the current priorities. The higher in the list, the higher the priority. The boards are currently separated by task size and they are:

• Small
• Medium
• Large

We recommend new contributors start with small tasks and gradually work their way up to large tasks. But this shouldn't discourage you from starting with a large task if you're really passionate about working on one of them. Just make sure you check out the guidelines in the next section first.

The Life of a Change

Changes can be small, medium, or large and there are different guidelines for each size of change. If you're unsure which guidelines to follow, simply ask on Discord and someone will help you figure out the right path to submitting your change.

Small Changes

Small changes do not require a DIP or extended discussion. Simply submit a pull request to the relevant repository and you're done.

Examples of small changes include:

• Updating documentation
• Adding test coverage
• Fixing small bugs that don't affect consensus
• Correcting inconsistent APIs, logging, or configuration options
• Upgrading dependencies
• Clarify DIP process

Medium Changes

For medium changes, please create a new Discussion on the DIPs repository. You should explain the change you'd like to make, the rationale for making the change, and how you plan to implement the change.

Once a core dev approves your idea you can get to work and open a pull request on the relevant repositories. You do not need to open an issue or pull request on the DIPs repo.

Examples of medium changes include:

• Adding a new API endpoint
• Redesigning a frontend component
• Adding new configuration options
• Refactoring one package or a few files
• Change the DIP Process, excl those listed below under Large changes

Large Changes

For large changes, a little more work is required. In order, you should:

1. Create a new Discussion on the DIPs repo to get buy-in for your work from the community and at least one core dev. This is not always required. For example, if a core dev already approved your idea then you can skip this step. Additionally, note that we are actively working to expand the group of core devs.
2. Once the community and at least one core dev approves your proposal, create a pull request on the DIPs repo describing your change in full detail. Use the DIP template for creating your DIP.
3. The community and core devs will review your DIP PR and provide feedback. Once at least two core devs approve, your PR can be merged and is now an official DIP.
4. Now that you have an official DIP, you can confidently submit pull requests to the relevant repositories to implement your changes. You can also enlist other community or core developers to help you.
5. Once your PRs have at least two approvals from core devs, they can be merged and your change can go live on the network.

Examples of large changes include:

• Changing or adding a transaction
• Any soft or hard fork to consensus
• Refactoring multiple packages or repositories
• A significant change to the DIPs process, including:
  • Change levels & their definitions
  • Who approves changes at different levels

dips's Issues

Can we get coin locking to protect rug pulls and make investors comfortable, I need this ASAP PLEASE

Please propose new CIPs by creating a new Discussion.

I think it would be good if you could see ownership history of an NFT.

Yes. Agree, especially if friends are just buying NFTs from friends. Seems to be the case in many instances)

Originally posted by @KrassensteinBitClout in #92 (comment)

Bitclout Galleries.

Create system so that once someone has joined bitclout, they are able to create a collaborative gallery with with other biclouters within bitclout. To start off with it would be best to keep splits equal, yet over time this tool could be more sophisticated.

This would be good tool for NFT's, gallery can publish with the artist, in an open and transparent way. When the NFT sells from the gallery all parties are paid at point of sale.

Often artists have to wait to paid till the financial situation is good for the gallery/publisher.

Why? This would allow people to make works together. This is essentially something similar to what organisations like ASCAP and BMI are already doing.
What do they do? For allowing people to use their content and get paid under the laws of copyright, they are taking a percentage for doing that work, and then passing what is left over onto the artist. Mostly these rights organisations are non-profit organisations. They take a cost for verification and admin of creative works. However as most works publicly broadcast are owned by fewer companies, they have less relevance to self publishing artists.

Avatar shapes inconsistent across layout— not really an "issue" but... requesting feedback

I'm super excited about all the UX tweaks and how modernized things are starting to look. 🥰
@carsenk @AdityaChaudhary0005 @harpreet9629 and others are doing wonderful things in way of making the frontend feel more current with today's interface trends. That said, I noticed on a live build that there are some inconsistencies with the avatar shapes.

• The new account switcher has a circle avatar
• Most of the site uses a square avatar with rounded corners
• The main profile pic on each profile is firmly square

After all the work that has been done, I don't want to take it upon myself to PR against others work (especially recent work.)

I think we should come to consensus about one style for all the avatars.

Asking for community feedback about which you'd vote for:

• Circle
• Rounded Corner Square
• Square

Thank you.

Sources transaction field: SUBMIT_POST

NOTE: This issue should be converted to a discussion when discussions are available. At the moment, they are locked.

---

cip: To be assigned
title: Sources field for SUBMIT_POST transactions
author: Hunter Paulson <@HPaulson>
discussions-url: To be added
created: 2021-07-07
Note: This is a CIP duplication of bitclout/core #32

---

One-Line Description

Add a new Sources field added to SUBMIT_POST transaction types to allow applications to specify where a post is meant to display.

Explanation and Motivation

Provide a simple explanation of the CIP.

As the BitClout ecosystem expands, and many new applications are built on top of the protocol, having a standard for node-specific content will become vital. For example, if an engineer wanted to create an app built on top of the protocol which only displayed posts meant for that app (For example, if you wanted to make a Reddit-like app, it wouldn't make sense to display all posts from all subreddits on one twitter-like feed), the app could formulate a field like such in the request: Sources: ["myApp.com"]. BitClout.com, and any other nodes looking to display all content, could use the "Default" source to signify it displays regular content not specific to an application type. Those nodes could filter by this source. This could allow engineers to display posts only allowed for their source, without doing anything too hacky.

I think for the long-term success of BitClout we need many types of applications built on top of the protocol, and additions like this would be very very helpful in accomplishing such.

Specification

Backend

The new field, Sources: []string, should be added to typings for both PostEntryResponse and SubmitPostRequest. Additionally, the SubmitPost function should be updated to include the data from Sources in its call to CreateSubmitPostTxn`.

In addition, the backend may want to add a conditional to check if a post is meant for itself -- though this would be up to the discretion of the node operator. A possible solution is adding a backend flag that designates what such node uses as its source. For example, --source bitclout.com would active such a conditional to only return posts which include bitclout.com in its Sources array, where no flag would include all posts regardless of its Sources.

Core

The CreateSubmitPostTxn function should be updated to accept the Sources data as a parameter. The Source field should also be added to the SubmitPostMetadata struct with its appropriate []byte type. Finally, the usages of SubmitPostMetadata should be updated: Main, Test

Frontend

The SubmitPost method should be updated to include Sources: Array<string> as an parameter, and should include such as an argument when calling the Api post function. Additionally, the submitPost method should be updated accordingly, including Sources: ["bitclout.com"] in it's call to SubmitPost().

Other Solutions

While methods for accomplishing such a task already exist, for example hiding a post by default and making use of PostExtraData to identify the source application & if the post is actually hidden or not, however, I think having a standard method of doing such would be a much better, and long-lasting, solution.

Backwards Compatibility

There are no issues with backward compatability

Test Cases

The only required test should be an update to TestSerializeSubmitPost, as described above.

Security Considerations

None.