This seems reasonable to me. Do you see this as conflicting with the proposed json schema for twitter-like posts?
Maybe? I guess we should set up an EIP-like repo for PIPs.
Some thoughts:
-
Is it really okay to “store” the message in blocks but not in the state? As the chain lives longer and longer, there might be less and less people storing the whole block history. I’m confident there will still be people and companies doing it, but when the storage reaches tens of terabytes, it might be highly skewed towards companies offering paid API access (arguably this can be unbundled, decentralized too though). It might be okay, but it’s worth thinking about explicitly. Otoh, storing in the state makes the costs prohibitive.
-
Has someone looked at how Arweave incentivizes storage? They seem to have done some thinking of that front. Maybe something similar can be reproduced / incentivized by a contract?
A different type of general purpose contract can be made via unicodes. Emojis, logographic symbols can be send via this contract as well.
contract Poster {
event NewPost(address indexed account, uint256[] unicodes);
function post(uint256[] calldata unicodes) public {
emit NewPost(msg.send, unicodes);
}
}
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 
1 Like
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.
1 Like
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.
1 Like
@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.
1 Like
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.
2 Likes
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 
