HomeEIPsNewsletter
EIPsERC-1129
ERC-1129

Standardised DAPP announcements

StagnantStandards Track: ERC
Created: 2018-05-31
Jan Turk (@ThunderDeliverer)
Discussions ForumOriginal Proposal LinkEdit
1 min read

The ERC-1129 proposal aims to standardize the way DAPP developers and service providers announce changes or updates to their services on the Ethereum network. It defines a format for posting announcements and removing them, as well as posting permissions and a human-friendly interface. The proposal includes two structures: Announcer, which stores information about the announcement maker, and Announcement, which stores information about the individual announcement. The proposal also includes a method to retrieve the number of active announcements. The motivation behind the proposal is to provide guidelines for notifying users of service status and to increase the quality of service provided by DAPP developers and service providers. The proposal is meant to be deployed as a Solidity smart contract on the Ethereum network.

Video
Anyone may contribute to propose contents.
Go propose
Original

Simple Summary

Standardisation of announcements in DAPPs and services on Ethereum network. This ERC provides proposed mechanics to increase the quality of service provided by DAPP developers and service providers, by setting a framework for announcements. Be it transitioning to a new smart contract or just freezing the service for some reason.

Abstract

The proposed ERC defines format on how to post announcements about the service as well as how to remove them. It also defines mechanics on posting permissions and human friendly interface.

Motivation

Currently there are no guidelines on how to notify the users of the service status in the DAPPs. This is especially obvious in ERC20 and it's derivates. If the service is impeded by any reason it is good practice to have some sort of guidelines on how to announce that to the user. The standardisation would also provide traceability of the service's status.

Specification

Structures

Announcer

Stores information about the announcement maker. The allowedToPost stores posting permissions and is used for modifiers limiting announcement posting only to authorised entities. The name is used for human friendly identifier of the author to be stored.

struct Announcer{ bool allowedToPost; string name; }

Announcement

Stores information about the individual announcement. The human friendly author identifier is stored in author. Ethereum address associated with the author is stored in authorAddress. The announcement itself is stored in post.

struct Announcement{ string author; address authorAddress; string post; }

Methods

the number of announcements

Returns the number of announcements currently active.

OPTIONAL - this method can be used to provide quicker information for the UI, but could also be retrieved from numberOfMessages variable.

function theNumberOfAnnouncements() public constant returns(uint256 _numberOfAnnouncements)

read posts

Returns the specified announcement as well as human friendly poster identificator (name or nickname).

function readPosts(uint256 _postNumber) public constant returns(string _author, string _post)

give posting permission

Sets posting permissions of the address _newAnnouncer to _postingPrivileges and can also be used to revoke those permissions. The _posterName is human friendly author identificator used in the announcement data.

function givePostingPermission(address _newAnnouncer, bool _postingPrivileges, string _posterName) public onlyOwner returns(bool success)

can post

Checks if the entity that wants to post an announcement has the posting privilieges.

modifier canPost{ require(posterData[msg.sender].allowedToPost); _; }

post announcement

Lets user post announcements, but only if they have their posting privileges set to true. The announcement is sent in _message variable.

function postAnnouncement(string _message) public canPost

remove announcement

Removes an announcement with _messageNumber announcement identifier and rearranges the mapping so there are no empty slots. The _removalReason is used to update users if the issue that caused the announcement is resolved or what are the next steps from the service provider / DAPP development team.

function removeAnnouncement(uint256 _messageNumber, string _removalReason) public

Events

New announcement

MUST trigger when new announcement is created.

Every time there is a new announcement it should be advertised in this event. It holds the information about author author and the announcement istelf message.

event NewAnnouncement(string author, string message)

Removed announcement

MUST trigger when an announcement is removed.

Every time an announcement is removed it should be advertised in this event. It holds the information about author author, the announcement itself message, the reason for removal or explanation of the solution reason and the address of the entity that removed the announcement remover.

event RemovedAnnouncement(string author, string message, string reason, address remover);

Rationale

The proposed solution was designed with UX in mind . It provides mechanics that serve to present the announcements in the user friendly way. It is meant to be deployed as a Solidity smart contract on Ethereum network.

Test Cases

The proposed version is deployed on Ropsten testnet all of the information can be found here.

Implementation

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by