RSS3 Protocol v0.4.0 Adventure

[DIYgod]

Summary of discussions

1. Channel/community feature RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
2. NFT PFP RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
3. User Relationship Maintenance RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
4. IM feature RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
5. Privacy RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (reply in thread) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
6. More Supported Networks/Data RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
7. Custom fields RSS3 Protocol v0.4.0 Adventure #25 (comment)
8. Recommendation and search RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
9. Auto items management RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
10. Censorship RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
11. Identity verification RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (reply in thread) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment) RSS3 Protocol v0.4.0 Adventure #25 (comment)
12. Protocol boundary RSS3 Protocol v0.4.0 Adventure #25 (reply in thread)

To be continued

SERIOUS DISCUSSION ONLY

Please stop the pointless replies, it doesn't do any good.

Please note that this forum is for serious discussion of the protocol v0.4.0 for developers, do not discuss unrelated content in this forum, spam will be reported and blacklisted on GitHub.

Developers who participate in meaningful discussions will be rewarded with a special POAP or NFT(RSS3 Fruit Token) to be used in future DAO. A separate email will be sent after v0.4.0 is released. Please ensure that the email is visible and available in your GitHub profile. For related queries please contact contact@rss3.io

Let's get the adventure started!

We prepared a draft proposal v0.4.0 based on many problems encountered in the use of v0.3.1. But limited by the ability of a few people, the draft may contain many errors and poor design, which is the reason for the need for extensive participation in the discussion and this draft may differ significantly from the published version depending on the discussion and feedback.

About RSS3 Protocol

We've seen the Web1 era when everyone was happy to use RSS as a standard format for syndication and the Web2 era when RSS declined and the closure of information between platforms are created.

We all agree that information should be more freely distributed in the Web3 era, and to facilitate this we need a common format that we can all use to syndicate information, reducing the cost of use and development. So we created a new protocol RSS3, RSS stands for a tribute to the history and 3 stands for Web3.

Please distinguish the RSS3 protocol from the RSS3 network, which is an implementation based on the RSS3 standard.

URI

Inspired by Manifesto for Ubiquitous Linking and 让链接无处不在——《泛在链接宣言》的理论与理想, we have replaced a large number of id fields in the previous version with accessible URIs to make it easier for users to access the data.

These URIs meet the RFC 3986 specification, the scheme is rss3, userinfo is the instance address and host is the account platform, e.g. evm solana flow.

type SignableAccount = string;          // ${address}@${SignablePlatform}, for example, 0x1234567890123456789012345678901234567890@evm
type UnsignableAccount = string;        // ${address}@${UnsignablePlatform}, for example, rss3_@twitter

type InstanceURI = string;              // rss3://${SignableAccount}

type ItemURI = string;                  // ${InstanceURI}/${'notes' | 'assets'}/${uuid}
type ItemPageListURI = string;         // ${InstanceURI}/list/${'notes' | 'assets'}/page/${index}
type ItemListURI = string;             // ${InstanceURI}/list/${'notes' | 'assets'}

type LinkListURI = string;             // ${InstanceURI}/list/links/${InstanceURI | NoteURI | AssetURI}/${index}
type BacklinkListURI = string;         // ${InstanceURI}/list/backlinks/${URI}

type URI = string;                      // Any uri
type URIs = URI[] | URI;                // A series of uris pointing to accessible resources

File Base

Each file has a number of base fields, and the files are classified as signed or unsigned, signed files are used for user submitted and authorized files, unsigned files are used for files that are automatically indexed by the nodes of the RSS3 network

InstanceURI ItemPageListURI ItemListURI LinkListURI BacklinkListURI five URIs point to RSS3 files, the ItemPageListURI and LinkListURI are user-signed files, the index at the end is to facilitate file signing and paging, the first page is 0, the second page is 1... ItemListURI and BacklinkListURI are unsigned files, generated by the nodes of the RSS3 network, and do not require signature verification

interface Base {
    version: 'v0.4.0'; // Proposal version for current file. It should be like `v1.0.0`
    identifier: InstanceURI | ItemPageListURI | ItemListURI | LinkListURI | BacklinkListURI;
    date_created: string; // Specifies the created date in RFC 3339 format
    date_updated: string; // Specifies the updated date in RFC 3339 format
}

interface SignedBase extends Base {
    signature: string; // Signed by instance's private key, the signature message is JSON string sorted by key alphabet: `[RSS3] I am confirming the results of changes to my file ${identifier}: JSON.stringify(file, Object.keys(file).sort())`
    agents?: {
        pubkey: string; // A random ed25519 public key generated by the client
        signature: string; // A signature signed by pubkey's private key, the message is the same as `signature`
        app: string; // Name of the app using this agent, eg: Revery
    }[];
}

interface UnsignedBase extends Base {
    auto: true;
}

Index File

The Index file is the entry for each RSS3 instance and is the most important file.

The standard and implementation of controller is uncertain and it is a reserved field.

profile defines the information about the instance itself, the accounts field is used to bind other accounts, both centralised and decentralised, e.g. evm solana twitter playstation; the banners websites field has been added.

links defines the relationship between the current instance and any other URI, e.g. defining a relationship called following, its list can contain other RSS3 instance, an RSS address, or an RSS3 Note; identifier_back is the reverse relationship, i.e. the relationship that other URI point to the current instance.

items is the most important field, and the one we consider most and least certain; notes (the name derives from Misskey, previously called items) are used for the feed, identifier_page contains the dynamics of the user's own posting, confirmed by the user's signature, such as a blog post or a message, and identifier additionally contains the dynamics automatically indexed by the nodes of the RSS3 network, such as the acquisition of an NFT; assets are assets owned by the instance, such as an NFT or a trophy won in PlayStation

interface Index extends SignedBase {
    identifier: InstanceURI;
    controller?: string; // A contract address indicating ownership of the file

    profile?: {
        name?: string;
        avatars?: URIs;
        bio?: string;
        banners?: URIs;
        websites?: URIs;
        accounts?: ({
            account: SignableAccount | UnsignableAccount;
            signature?: string; // Signature of `[RSS3] I am adding ${SignableAccount} to my RSS3 instance ${InstanceURI}`
        })[];
    };

    links: {
        identifiers?: LinkListURI[];
        identifier_back: BacklinkListURI;
    };

    items: {
        notes: {
            identifier_page?: ItemPageListURI;
            identifier: ItemListURI;
        };
        assets: {
            identifier_page?: ItemPageListURI;
            identifier: ItemListURI;
        };
    };
}

Items

Items is the biggest change apart from the URI.

Previous versions of items have been renamed notes and previous versions of items+assets have been combined as items.

notes and assets have the same format

links of items are in the same format as links of instances

contents in the previous version renamed to attachments to record resources such as images attached to notes or assets.

metadata added to standardise the content indexed by the nodes of the RSS3 network.

type Item = {
    identifier: ItemURI;
    date_created: string; // Specifies the published date in RFC 3339 format
    date_updated: string; // Specifies the modified date in RFC 3339 format

    links: {
        identifier_back: BacklinkListURI;
        identifiers?: LinkListURI[];
    };

    tags?: string[];
    authors?: InstanceURI[];
    title?: string;
    summary?: string;
    attachments?: {
        content?: string; // Actual content, mutually exclusive with address
        address?: URIs; // URIs of same resource pointing to third parties, mutually exclusive with content
        mime_type: string; // [MIME type](https://en.wikipedia.org/wiki/Media_type)
        name?: string;
        size_in_bytes?: number;
    }[];

    metadata?: {
        proof: string; // transaction, url, etc.
        type: AutoAssetType | AutoNoteType | 'custom';
        from?: string;
        to?: string;
        id: string; // unique id, eg: ${token_address}-${token_id}
    }

    auto?: true; // For auto items
};

List Files

The format of the list file is simple and has not been changed significantly.

interface ListBase<URIType, ElementType> {
    identifier: URIType;
    identifier_next?: URIType;
    list?: ElementType[];
}

type ItemPageList = SignedBase & ListBase<ItemPageListURI, Item>;
type ItemList = UnsignedBase & ListBase<ItemListURI, Item>;

type LinkList = SignedBase & ListBase<LinkListURI, URI>;
type BacklinkList = UnsignedBase & ListBase<BacklinkListURI, InstanceURI | ItemURI>;

Overall

// word lists
type SignablePlatform = 'evm' | 'solana' | 'flow';
type UnsignablePlatform = 'twitter' | 'misskey' | 'jike';
type LinkType = 'following' | 'comment' | 'like' | 'collection';
type AutoAssetType = 'evm_gitcoin_donation' | 'evm_xdai_poap' | 'evm_bsc_nft' | 'evm_ethereum_nft' | 'evm_polygon_nft';
type AutoNoteType = AutoAssetType | 'evm_mirror_entry' | 'twitter_tweet' | 'misskey_note' | 'jike_node';

// unique id
type SignableAccount = string;          // ${address}@${SignablePlatform}, for example, 0x1234567890123456789012345678901234567890@evm
type UnsignableAccount = string;        // ${address}@${UnsignablePlatform}, for example, rss3_@twitter

// uri
type InstanceURI = string;              // rss3://${SignableAccount}

type ItemURI = string;                  // ${InstanceURI}/${'notes' | 'assets'}/${uuid}
type ItemPageListURI = string;         // ${InstanceURI}/list/${'notes' | 'assets'}/page/${index}
type ItemListURI = string;             // ${InstanceURI}/list/${'notes' | 'assets'}

type LinkListURI = string;             // ${InstanceURI}/list/links/${InstanceURI | NoteURI | AssetURI}/${index}
type BacklinkListURI = string;         // ${InstanceURI}/list/backlinks/${URI}

type URI = string;                      // Any uri
type URIs = URI[] | URI;                // A series of uris pointing to accessible resources

// Common attributes for each files
interface Base {
    version: 'v0.4.0'; // Proposal version for current file. It should be like `rss3.io/version/v1.0.0`
    identifier: InstanceURI | ItemPageListURI | ItemListURI | LinkListURI | BacklinkListURI;
    date_created: string; // Specifies the created date in RFC 3339 format
    date_updated: string; // Specifies the updated date in RFC 3339 format
}

interface SignedBase extends Base {
    signature: string; // Signed by instance's private key, the signature message is JSON string sorted by key alphabet: `[RSS3] I am confirming the results of changes to my file ${identifier}: JSON.stringify(file, Object.keys(file).sort())`
    agents?: {
        pubkey: string; // A random ed25519 public key generated by the client
        signature: string; // A signature signed by pubkey's private key, the message is the same as `signature`
        app: string; // Name of the app using this agent, eg: Revery
    }[];
}

interface UnsignedBase extends Base {
    auto: true;
}

// RSS3 index files, main entrance for a instance
interface Index extends SignedBase {
    identifier: InstanceURI;
    controller?: string; // A contract address indicating ownership of the file

    profile?: {
        name?: string;
        avatars?: URIs;
        bio?: string;
        banners?: URIs;
        websites?: URIs;
        accounts?: ({
            account: SignableAccount | UnsignableAccount;
            signature?: string; // Signature of `[RSS3] I am adding ${SignableAccount} to my RSS3 instance ${InstanceURI}`
        })[];
    };

    links: {
        identifiers?: LinkListURI[];
        identifier_back: BacklinkListURI;
    };

    items: {
        notes: {
            identifier_page?: ItemPageListURI;
            identifier: ItemListURI;
        };
        assets: {
            identifier_page?: ItemPageListURI;
            identifier: ItemListURI;
        };
    };
}

// items
type Item = {
    identifier: ItemURI;
    date_created: string; // Specifies the published date in RFC 3339 format
    date_updated: string; // Specifies the modified date in RFC 3339 format

    links: {
        identifier_back: BacklinkListURI;
        identifiers?: LinkListURI[];
    };

    tags?: string[];
    authors?: InstanceURI[];
    title?: string;
    summary?: string;
    attachments?: {
        content?: string; // Actual content, mutually exclusive with address
        address?: URIs; // URIs of same resource pointing to third parties, mutually exclusive with content
        mime_type: string; // [MIME type](https://en.wikipedia.org/wiki/Media_type)
        name?: string;
        size_in_bytes?: number;
    }[];

    metadata?: {
        proof: string; // transaction, url, etc.
        type: AutoAssetType | AutoNoteType | 'custom';
        from?: string;
        to?: string;
        id: string; // unique id, eg: ${token_address}-${token_id}
    }

    auto?: true; // For auto items
};

// RSS3 list files
interface ListBase<URIType, ElementType> {
    identifier: URIType;
    identifier_next?: URIType;
    list?: ElementType[];
}

type ItemPageList = SignedBase & ListBase<ItemPageListURI, Item>;
type ItemList = UnsignedBase & ListBase<ItemListURI, Item>;

type LinkList = SignedBase & ListBase<LinkListURI, URI>;
type BacklinkList = UnsignedBase & ListBase<BacklinkListURI, InstanceURI | ItemURI>;

Edited By NaturalSelectionLabs

[kecrily]

What is the most essential difference between notes and assets?

[hh77hh88kt218]

觉得非常不错。有点期待

[hikafeng]

good , wish better more，may RSS To the moon

[DIYgod]

@kecrily I think the difference in their usage scenarios is big enough to worth separating them, and I think there are almost no scenarios where notes and assets are used together

[rapiz1]

I think the difference in their usage scenarios is big enough to worth separating them

The difference in usage scenarios can be a reason for splitting them into different concepts. But not a strong reason to split them into completely different data structures. The current situation shows that these two kinds of objects are quite similar and abstraction can be used here to help reduce the redundancy. What about using an enum to distinguish them? Or introducing an interface ItemBase to include identifier_page and identifier.

However, I lean on using a single structure to represent both notes and assets, as explained below.

I think there are almost no scenarios where notes and assets are used together

I think in the context of web3, notes are essentially assets. Though it's unlikely that one wants to show all his tweets as assets, showing a selective set of tweets as assets is a very attractive usage. Like showing tweets about important moments, about loved ones, and so on, as assets. Why aren't these tweets not assets?

[dushaobindoudou]

Although some information is not of high value, it is not necessarily an asset. Even Twitter should have copyright, so there is no need to distinguish, but it is necessary to prevent a large amount of spam

[blokslabs]

看不太懂具体的功能什么的，能不能写具体一点，让用户知道有什么功能，然后让用户在讨论中提出自己想要的功能。

[DIYgod]

About RSS3 Protocol section has been added to explain the purpose of this protocol

[fewwwww]

Why people downvoting this? I think @blokslabs is making a good point. Not everyone used RSS before, and they cannot easily handle so many new concepts.

[BodyHuang]

介绍太技术向，对非开发人员理解门槛太高，建议从产品功能层面介绍，带来了什么更新，提供了什么功能，解决了什么问题

[DIYgod]

Yes, this is GitHub, this is the developer community
About RSS3 Protocol section has been added to explain the purpose of this protocol

[popo2021]

今天看推特，发现和a链合作，看到rss3的合作伙伴越来越多让我很高兴啊。

[popotang050]

在币圈还是得看用户价值和收益，目前看来用户好像都没有啥收益，不知道发币以后会怎么样？

[jpettitt]

Looking at the protocol as a whole in the context of what already exists ...

Traditional RSS and Atom as they currently exists are transport protocols used for XML structured content that's typically metadata and links to assets. There are a number of flavors including things like media-rss. It seems like RSS3 is trying to be more than that and by expanding into other layers of the stack it starts to take on all the issues that go with those layers. For example profile a complex thing to get right on it's own. While some of these fields are nullable over specifying them makes extensibility harder.

My suggestion would be to consider strictly separating the layers, build something that handles distributed transport of links or attachments. Define separate mime-types for more complex data payloads. This will let people do the minimum work of just wrapping their classic RSS text/xml or application/atom+xml payload in an RSS3 chain layer (I suspect this is what people will do anyway, ignoring the optional fields).

[joshuaTTL]

This is actually a very interesting topic which we have been long thinking about. The standard should be separate from the network that runs it, which is true in practice - e.g. anyone can make RSS3 files and have them subscribed. However, we do find it challenging to see that approach landing in massive adoption in the current dataset landscape. I guess this writing might be helpful https://rss3.notion.site/9-The-Historical-and-Structural-Perspective-of-RSS3-cdcd237037b64d04b9759321cf298c72, but yeah more research is needed.

[jpettitt]

There seems to be a lot of overlap and blurred lines between protocol and business model. Just reading the comments here people are talking about token value and adding music, search engines etc. Those may all be perfectly valid things to build on top of a protocol, adding value and differentiating a provider. However if you want wide adoption of a protocol it needs to be clean and well bounded. Ideas that encompass whole swaths of the stack from low level transport formats to application and presentation are almost impossible deploy as broadly adopted standards.

Existing RSS is free, if there is any cost to publishing on this protocol it's going to be a very hard sell.

[DIYgod]

You're right, the protocol should be kept pure. But these are not the days of simple and pure Web1 anymore, and centralized applications can be easier to get a better experience. We find it hard to promote a standalone protocol, and the network and demos are also an important part of it. Reducing the cost of use for developers through easy access to RSS3 networks and SDKs, and engaging and guiding developers through demo applications makes things much easier and more efficient. But we also remember that RSS3 networking and the RSS3 protocol are two different things, developers can also implement their own networks using the RSS3 protocol, we will emphasize and delineate this more clearly in the next v0.4.0 document.

[DIYgod]

Just reading the comments here people are talking about token value and adding music, search engines etc. That wasn't our intention either, we also wanted people to simply discuss the protocol, but things were out of control 😅

[0xpatel57]

I'm glad to see that RSS3 keeps refining. IMHO, there are a few things RSS3 can improve:

1. Improve loading speed. I was about to follow a few RSS3 friends a few days ago, I found it was quite painful to wait so long for the "follow" button to become "following". I purposely picked non-rush hours to do so, however, it did need much patience. If a user lose his patience, you will lose that user.
2. Sorting content (users‘ NFTs/Twitter footprints/ POAPs etc) out in a more organized and neater way. For example, you can adopt a layout similar to an excel spreadsheet tab/workbook , users can switch to different tabs to see more information for certain categories (NFTs or POAPs) instead of putting everything that user owns in one single busy/crowded page.
3. Provide value and utility to the data/stats. For example, graphing or summarizing users' NFT profitability and returns (%) provide more value to the users versus just laying out all the NFTs that user owns/sells. Utilization of data is way important than presenting data, if RSS3 wants to go deeper and truly cares about winning its users.
4. Provide web3 search engine function. Web3 seems to lack of a powerful search engine (thinking of Google in web2...). If users can search through RSS3, isn't that fantastic?! - If users can search for ENS, twitter, ERC-20 address, etc, it would make users want to use more of RSS3. In short, keep adding value to RSS3 usage.
   Wish team achieve the next milestone soon and v.4.0 adventure becomes successful. Cheers!

[DIYgod]

Thanks, but as for 3, I think the real value of NFT is to collect and not to make money, and the positioning of Cheers and Revery is not the NFT market, there are many more beautiful things in life than making money.

[LHY-sudo]

现在的协议有没有对未来资产的预留？现在区块链发展很快，现在有poap，NFT等资产，后面肯定会有新的资产出现。建议增加一些预留。

[srdwinu]

新页面区块 Collectibles Donations 这些边界感不强，感觉有点凌乱 🤣

[itmanhuang]

Add search function, add focus list function

[ppkjjn]

希望可以在rss3上感受到用户web3.0的价值

[GODREKTs]

I just read about items. If Items is the biggest change other than URI can someone explain to me about Items before this, because in the text it's explained just changing the name or do merging.

[yuzuru99]

• make the display more attractive and add dark mode
• long page loading, it would be better if web3 was made faster
• profile page is better if it's on the left and for content on the right
• maybe it would be better to have a suggestion feature to follow someone

[arojayolo123]

Big congrats to the RSS3 token launch! I have been watching this project for a while, here are my 2 cents of making further improvements:

1. Draw a clearer picture of what RSS3 is going to achieve in web3 world. The contents seems to integrate a few intelligence feeds, but lack of focus and uniqueness.
2. Empower the governance token to give the community more rights to say where they want RSS3 to go. I am happy to see that RSS3 uses github as a forum to let community express their opinions. I hope to see more of this kind of discussions down the road. Would it be nicer to have a forum/community/discussion board on RSS3 portal itself? As a web3 info hub, I'm sure that RSS3 can be the center of heat drawing more attentions and be used by more users.
3. Launch more campaigns to interact with users and let RSS3 shine in the Web3 world. Token genesis is just the beginning of the journey. I hope to see more announcements about RSS3 interacting/cooperating with other protocols and bringing more utilities to the community. RSS3 as the infrastructure and hub of Web3, it needs to play a more active role in terms of educating and communicating with the entire crypto community.

[kootsZhin]

Will all this data encrypted in any way before posting on the network? Recently I was reading a paper on aggregating data on public network using zk-SNARK, I have not digested the whole paper yet but I guess this could be useful or somehow give some insight to the development of RSS3.

[kootsZhin]

Attaching the link to the article here: https://crypto.stanford.edu/prio/paper.pdf

[t-900-a]

Mask Protocol can be used to encrypt some of the fields. I.e. "summary", "title" The rest of the metadata I imagine will not be encrypted.

[bugpink]

Nowadays a large part of rss users are webmasters of some personal blogs. rss3, if it wants to replace rss, must be able to easily integrate with blogs/sites that use various technologies.

If the above vision is to be realized, it should not be like this: every time a product is added to support, it is developed by the rss3 team (e.g. mastodon which has not been supported for a long time).

Rather, the server side should be easy to generate a common rss3 data format that can then be used by a variety of products (currently rss3 can see client-side demos for revery and cheers)。Even if you adapt a new product, you should not change the code every time, but let the new product follow the protocol and it will work.

How does the rss3 team think about this?

[xlogiccc]

【数据控制相关】
背景：一个用户可能会生产很多内容或拥有很多资产，但是其中的一些内容和资产可能不想全部公开。

需求：是否考虑为 item 添加 setting 相关属性用来存储用户配置（不一定合理，只是举例），实现能够在 RSS3 中完成一次隐藏设置（软删除），所有其他上层应用授权使用 RSS3 服务时默认进行用户设置同步。

[popo2021]

这个现在还有poap送吗？