Peeps by @spengrah
Showing page 2 of 2 (66 peeps total)
Replying to @Xelion (0x7f4d762fa48d170a643337b49a50bc744c75bee0)
There are a lot of sidechains solutions with their own way to achieve consensus with the mainchain. Most of them use a set of validators that have to post all block headers of the sidechain on the mainchain. Known solutions are: PoA Network, Cosmos, DAppChains and Plasma. (2/2)
Thanks!
My understanding of state channels, though, is that they *do* offer the security of the main chain because they always maintain the option to adjudicate the state on the blockchain if there's a dispute.
Replying to @Xelion (0x7f4d762fa48d170a643337b49a50bc744c75bee0)
PoA sidechains offer fast and scalable chains with some per missioned trade-offs. Unlike state channels, it's a full blockchain with it's own validator set and it's own EVM. State channels respond to some very specific use cases while PoA sidechains can be used for any dapps.
I'm curious - what can you do with a PoA sidechain that you can't do with state channels?
Also, in what fashion is the sidechain connected to the main chain? I haven't learned much about sidechains yet!
Replying to @kartik (0xc912e55e813753f91f96054eacf4e342a6061f1a)
Any thoughts on poa.network ? I’m considering it as a stepping stone to launching something on public Ethereum
I'm also interested in hearing responses. How is proof of authority different than a trusted third party? State channels feel like a better alternative - what am I missing?
Any peepers out there into / working on TCRs?
Replying to @soule (0x6ea1eadb60d3c33113862035cf99fdc3854ca85e)
Who are some thoughtful eth product people on here? (Already following @tay)
Product people unite!
Replying to @Bevan (0x30755d3e65c0cf46c35b72d11e52d941c5fc3a3e)
Thank you, both self-hiding and threads are in the queue.
Awesome - can't wait!
Replying to @ndelgrande (0x5f25a10e44f69668cfba52cdb9a62903ba25fc24)
I can only think of another Blockchain that specializes in digital asset ownership. Actually multiple sources/chains to ensure it is correct.
FYI @Pinastri linked to a great idea from Vitalik for community moderating: https://ethresear.ch/t/prediction-markets-for-content-curation-daos/1312
Replying to @spengrah (0x26521ede6e1796c6faee57cbc68a178e78d8e23e)
But also, in addition to flags and a mechanism for community moderation, I'd like to see some flags added for self-moderation, e.g. to enable users to "remove" posts they no longer stand behind.
As an aside, I'd also like to see better threading, so all posts in a conversation can be viewed, instead of having to click on each post to see their replies.
(see this conversation for an example of some people's comments getting lost)
Replying to @spengrah (0x26521ede6e1796c6faee57cbc68a178e78d8e23e)
Agreed, this is some good stuff. Who'da thought that Vitalik guy would have a good idea? As Vitalik mentioned, an important piece will be designing the moderator to support a decentralized approach, preventing a malicious moderator.
But also, in addition to flags and a mechanism for community moderation, I'd like to see some flags added for self-moderation, e.g. to enable users to "remove" posts they no longer stand behind.
Replying to @Bevan (0x30755d3e65c0cf46c35b72d11e52d941c5fc3a3e)
Thank you. Will have a look at this.
Agreed, this is some good stuff. Who'da thought that Vitalik guy would have a good idea?
As Vitalik mentioned, an important piece will be designing the moderator to support a decentralized approach, preventing a malicious moderator.
Replying to @spengrah (0x26521ede6e1796c6faee57cbc68a178e78d8e23e)
Because of the multi front end problem, in addition to _hide_ there should be a _flag_ attribute. Could take many forms, including "removed by poster (for reason X)", "copyright infringement", "illegal content", etc. Front ends could then choose what to show/hide based on that
For the flags that are not necessarily set by the poster, the challenge, obviously, is how to reach consensus on a flag. For example, what's the oracle that can flag content as copyright infringement?
Replying to @ndelgrande (0x5f25a10e44f69668cfba52cdb9a62903ba25fc24)
Just to add to Andrew's post, the peep post data isn't saved on the Ethereum Blackchain. A IPFS address is stored which is read by the Dapp browser and loaded. To hide posts, another attribue can be created on the BC to show/hide.
Because of the multi front end problem, in addition to _hide_ there should be a _flag_ attribute. Could take many forms, including "removed by poster (for reason X)", "copyright infringement", "illegal content", etc. Front ends could then choose what to show/hide based on that
Replying to @abcoathup (0x13ebd3443fa5575f0eb173e323d8419f7452cfb1)
It is definitely a user education. Don’t peep what you don’t want future bosses, partners, grand kids to read. I think there will be a need for a hide (rather than delete) peep. There may be potential for an option to delete a peep prior to a batch save.
Ooo good point. The post-then-confirm-onchain pattern offers a good opportunity to enable correcting typos and other first-draft type mistakes.
Replying to @spengrah (0x26521ede6e1796c6faee57cbc68a178e78d8e23e)
I've been thinking about what it means for a post ("peep"?) to be immutable. That has anti-censorship advantages for sure, but what if I post something that I later realize is insensitive and I want to take it down?
Is owner-only delete a possibility, or does the blockchain state not allow that? If the latter, then perhaps the post-owner could flag the post as "withdrawn" or something. Could also include a reason for withdrawal or some related message.
Replying to @Bevan (0x30755d3e65c0cf46c35b72d11e52d941c5fc3a3e)
Greetings Spencer! All suggestions appreciated.
I've been thinking about what it means for a post ("peep"?) to be immutable. That has anti-censorship advantages for sure, but what if I post something that I later realize is insensitive and I want to take it down?
Hello peeps! Excited to give this a whirl