Right, I think the implicit assumption here is that protocols like The Graph will be able to make this data available in a decentralized way.
This is certainly possible, although I’d argue that it should be added as an additional layer to this contract, so as to keep Poster as opinionated as possible.
Is there a reason you couldn’t send these with the current Poster contract? Strings are assumed to be UTF-8 (unicode) encoded anyway.
Hey @auryn, what you have here is somewhat similar to what I proposed here, although this Poster contract is indeed surprisingly simple.
The major difference is your idea uses little storage on-chain, and the messages are not considered to be assets and hence not transferrable. The idea I proposed would treat every single word or logograph in some languages as an asset. The root cause is in the nature of languages.
That’s why I was wondering if this Poster idea could do the same.
Poster doesn’t use any on-chain storage.
Correct. Messages are not intended to be assets in Poster.
Honestly, I have no idea what this means. 
Postum update: https://postum.on.fleek.co/
https://github.com/ETHPoster/postum/tree/rinkeby
First try deploying, probably won’t stay up too long. Rinkeby only, definitely has some broken stuff. But you should be able to create forums, threads, and posts! I think this decently proves the concept outlined in this thread.
The UX isn’t ideal, but it’s at least part of the way there: you have to wait for the chain to confirm the transaction, but at that point the UI optimistically displays your action without waiting for the subgraph.
Feedback welcome! I’m not sure how much time I’ll have to put into this coming up, but I do think there’s a lot of potential in the forum use-case.
Just a heads up, EIP-3722 was merged, so it’s now ERC-3722 
Would it make sense to add another indexed field to the event that can be set by the poster?
For example
event NewPost(
address indexed user, // always msg.sender
bytes32 indexed tag,
string content
);
The idea would be that this could be used for easier querying of events if you don’t want to rely on a subgraph.
It could, potentially, but this feels like a slippery slope towards it becoming more opinionated.
I believe @crazyrabbitLTC also suggested a variety of other parameters that we might include to allow for better filtering for some usecases. We ultimately decided against it in the interest of keeping it as simple, elegant, and opinionated as possible.
Are there specific use-cases you’re thinking about?
I personally with thinking about allowing more direct communication (e.g. similar to a group around a topic).
While using a sub-graph obviously would still allow this when this is part of the content, I feel like it would be nicer to allow more efficient querying of on-chain data via traditional/ direct means would be very helpful and beneficial. Knowing that many nodes impose limits when querying events it would make sense to provide some method of filtering, therefore an additional field would be helpful.
@rmeissner what are your thoughts on using string rather than bytes32 for the tag, just to maintain human readability?
I was choosing a bytes32 because values that are indexed are forced to be 32 bytes (to fit in the topic field). So if you use a string it will be hashed and the hash will be store in the event topic (see Contracts — Solidity 0.8.9 documentation). So to be more flexible in what this actually is I was directly proposing to use bytes32, but on a low level using string would be a similar result, so I would be fine either way.
Cool, I’m convinced then. I’d like to stick with string to keep it human readable.
PR to add string tag parameter.
Follow the recording of PEEPanEIP#53: EIP-3722: Poster with Auryn Macmillan for an overview of the proposal, interesting use cases, proof of concept for a Twitter like feed, decentralized discussion forum on testnet.
Thanks for posting this, was an interesting listen. Wondering what the news is these days?
From my recent work doing hackathons, here are some “Boilerplates” from workshops that I found pretty cool:
and this one from Mr Yusef’s awesome IPFS workshop at Chainlink Fall Hackathon
@auryn thanks for your hard work building public goods!
I’ve been working for a few months on the “hackathon team building problem” (random strangers needing to trust and work together in a short time to build something) and really like the title Hackathon Registry, where each user/player, by building and through the reviews of their teammates, gets to grow their reputation. Will have another prototype out by the end of the January 
I find the code section under “Standard json format for Twitter-like posts” confusing. Is this supposed to be normative? E.g. does any of the list’s elements need filling out? Or is this more supposed to mimick JSON schema’s oneOf semantic? Are these just examples?
For the emission event itself can event NewPost(address indexed user, string content, string indexed tag); string content also just be a regular link (“https://” or “ipfs://”)? Or is it intended to contain e.g. text content?
