RE edicted: RE Taskmaster: Using Hive's Built-in Messaging System...

chat app

Reading @edicted 's comment about tagging in titles, surely edicted is pleased to see it continue.

In this article we are going to discus the feature of messaging on hive for communities.

It started with @taskmaster4450 who has posted:

Using Hive's Built-in Messaging System To Create An Alterlative To Discord
@taskmaster4450/using-hive-s-built-in-messaging-system-to-create-an-alterlative-to-discord

edicted has replied in

@edicted/re-taskmaster-using-hive-s-built-in-messaging-system
along with feedback written in comments by: @acesontop @alex-rourke @antisocialist @bozz @canna-curate @cmplxty.leo @cronicasdelcesar @darkflame @devpress @dudeontheweb @eatthebugs @edicted @emprendemesta @forexbrokr @gadrian @geneeverett @grider123 @jarvie @jfang003 @joetunex @josediccus @lacking @loving-kindness @magnacarta @manniman @mcsamm @metzli @mistakili @oldtimer @olympicdragon @quinnertronics @rt395 @rynow @rzc24-nftbbg @sepracore @shawnlauzon @stayoutoftherz @stdd @thaddeusprime @themarkymark @tobetada @tokenizedsociety @trostparadox @typebox @urun @wrestlingdesires @x9ed1732b @xplosive @yintercept @zestimony60 @zottone444

, who I think might be interested in this discussion.

A summary of the posts about was about creating a chatting application on Hive like Discord. It mentioned that many communities on Hive depend on it and while it is working fine, it is centralized, requires users to be on registered on another website and requires community owners to register on another website to provide chat for their community.

The posts then mentioned sending messages on Hive via transferring 0.001 HIVE or HBD, possibility of using customJSONs and finally of offloading the chat data from chain but still relying on memo key for authentication.

It mentioned that there is maybe lack of interest for programmers to create such application, but there has been attempts, such as BeeChat. While the client is open-source, the server is not.

So can we build it? Or?

Let's say we can build such an application! A chat application build by community for community. Features, ideas, feedback, testing the prototype, using it for your community, reblogging, supporting proposals, programming are all ways a comminity can contribute.

But first, let's discuss what we are going to build.

There is no need to make a copy, we can create a better version, add more features over time, but first we could start from the basics and add extras later.

The idea is to build a decentralized chat application on Hive for Hive communities. User would login with keychain, set up their community chat channels and be able to invite others by sharing a link. Naturally, all subscribers to your community would already be part of it. Ideally, even people not on Hive might be able to participate in the chat as long as the permissions of that community allow it.

I think the latter feature is required so that Hive community that is interested in onboaring users would have easy time doing it with a chat application that allows guest users.

The decentralized part would come with its API, and others would be able to create their own frontend, embed it or create chat bots, or run their nodes.

If you are you community owner, what features would you require? What features would you like to add? Let us all know, as if this application is built, it is built for you and your communities.

What does decentralized mean?

After looking how the terms "centralized" and "decentralized" are used in edicted's post, I'd like to share how I understand the term.
There are many decentralized protocols that are not blockchains, such as p2p networks, ipfs. On the other hand, ideal blockchains area decentralized and have decentralized consensus mechanism. It is not decentralization that makes it expensive, but rather the consensus mechanism. Decentralization of server nodes provides us with redundancy and reduces the ability a malicious node silently droping messages. Decentralized consensus mechanism, on the other hand, makes sure we have an decentralized agreement on the order the messages arrived in. It is this part that is expensive.
Now, let's say we drop the latter feature and stick with decentralization only. While chat messages come with their own timestamps, the decentralized nodes can check if the timestamps are within reasonable limits, in other words everything works as expected if the chat nodes and users are not malicious. What if a node is malicious or if it loses internet connection yet still has messages to broadcast? After it reconnects, and broadcasts the messages, they will come in late, and other nodes will notice it. They can add the message to the chat log either at signed client time (up to a certain limit) or at time they received it. In both cases they can mark the message as delayed so people in chat will be notified of it.

The key feature of chat application is message authentication. By using posting or memo key we can sign a message, which can then be verified by the recipient. With signing messages, anyone could impersonate any other user, and such application would be unreliable. Message authentication also ensures that even chat nodes cannot impersonate a user. Chat nodes simply pass the messages to interested parties. Decentralization ensures redundancy of storage and access.

Thank you for feedback.

The post @mirafun/decentralized-hive-communities-chat-app-with-similar-uiux-to-discord
has brief information about creating such application and have received a lot of feedback over the past days. I'd like to thank @engrave and others for asking many interesting questions and providing feedback.

To summarize, the most frequent question was wether the chat application will store the messages on chain.
The answer to that is no. There are many reasons why this is advantageos. First, it does not use Resource Credits of users. Second, it won't put pressure on chain in case the chatting application would be used frequently. Third, it is easier to add support for guest/lite accounts. Editing, deleting messages and storing them for set amount of time according to the preference of community owners and ability of nodes can be supported.

Another question received was about BeeChat, Peakd new messaging protocol plan. What would make this application different?
The main difference over BeeChat would be feature-set. BeeChat cannot yet be used to manage communities as in Discord and there is no telling when, if ever, it will get such features. Furthermore, the BeeChat server is not open source.
Peakd new proposal includes a messaging protocol idea, called "Sting". Now, my naming sense is not ideal, but I think calling it something like "Pollen" would be more appropriate. Anyways, it might be possible to collaborate with (@asgarth @peakd) if they are open about it, which i think they are.

Next question was about the project's marketing plan.
The chatting application is aimed for communities. The main users are community owners. The first requirement the app will have to meet is to provide the necessary features a community owner expects. For example such as creating channels, permissions, invite links with guest account support. It might be that this will be enough and the application will find some users if community owners pick it up. What features do you think would make a community owner think to use the app?

What's next?

To start things off, a frond-end prototype could be created. Work on interface has already been started.

settings
settings interface; the setup data is stored in json object on chain

While not yet finalized, here is an example of a customJSON used to store the community chat settings:

[
  "updateProps",
  {
    "community": "hive-1111111",
    "props": {
      "settings": {
        "streams": [
          {
            "na": "About",
            "nu": "about,rules,team"
          },
          {
            "na": "Posts",
            "nu": "created"
          },
          {
            "na": "Text"
          },
          {
            "na": "General",
            "nu": 0
          }
        ]
      }
    }
  }
]

In addition to adding chat channels, the about page, rules, community posts or a post from permlink can be added.

info
apart from text channels, information channels can be added

The application supports community roles and titles which will be used to manage channel permissions.

roles
adding a role; additional user interface to be provided when clicking on user

How can community support this project?

As part of community, you can:

  • share this post
  • share your ideas and feedback
  • request a feature
  • try prototype once its released
  • support DHF proposal

DHF proposal:
There is a proposal for programming the front-end and back-end, which you can support here:

Thank you for your time and your feedback. 🌻

H2
H3
H4
3 columns
2 columns
1 column
40 Comments
Ecency