Last week I spent every waking moment coding Myrme. I haven’t been this consumed by flow in years. I even thought I permanently lost that ability. But, *does prayer dance*, that turned out to be false. I could never order myself to get into the state of flow. Like falling in love or falling in general, it’s something that happens to you rather than something you decide to do. A mysterious force either takes you or doesn’t. Last week it did.
When you get around to messing with smart contracts, I highly recommend checking out the Pact smart contract language (https://github.com/kadena-io/pact). It's based on lisp, is more expressive than solidity, and is maintained by an incredible engineering team (I have no affiliation with them btw). I've messed around with a few other "smart contract languages" as well, and Pact has been by far my best experience. That being said, if the primary goal in learning solidity is just to get a feel for smart contracts, then its probably not a terrible place to start due to the massive amounts of documentation
The approach to not care about decentralisation at first is the right one, imo. Who cares if it's decentralised if you can't use it in the first place?
Please don't waste time with Solidity, "smart contracts" and other hocus-pocus that doesn't work. Unless you are looking to raise money - then sure, VCs love the jargon.
For decentralization I would advise you to look into https://github.com/fiatjaf/nostr - very simple approach that should scale without any problems.
Shouldn't the decentralized infrastructure be built in parallel with the UX? First, "decentralized" itself is a big magnet for new users these days. Second, if The Cloud wants to ban you, it'll be a race against them.
I think it would dramatically slow down development and iteration. Getting shut down early on is a much smaller risk than failing to build a compelling experience. (Relatively) few small projects get shut down. Almost all small projects fail to develop a compelling experience.
But yes, I agree in general that decentralization work should be done in parallel. But IMO not on day one.
I think Slava's approach is the right one. Building a social network is risky. Most fail. Building a decentralized social network is even riskier and the right way to do decentralization is still an open question. Better to tackle one problem before the other and since a lot of decentralization problems are only going to be apparent at scale it's better to get the social network side working first before focusing on decentralization.
Myrmecology is the study of ants which I think is coincidentally fitting for a social network
That's why I picked it!
When you get around to messing with smart contracts, I highly recommend checking out the Pact smart contract language (https://github.com/kadena-io/pact). It's based on lisp, is more expressive than solidity, and is maintained by an incredible engineering team (I have no affiliation with them btw). I've messed around with a few other "smart contract languages" as well, and Pact has been by far my best experience. That being said, if the primary goal in learning solidity is just to get a feel for smart contracts, then its probably not a terrible place to start due to the massive amounts of documentation
I love their lispy examples! Thanks!
The approach to not care about decentralisation at first is the right one, imo. Who cares if it's decentralised if you can't use it in the first place?
Can I be a part of the app's early-user group?
Not quite yet, but zero cred ppl will be first in line!
Do you have any plans to use handshake (handshake.org) in conjunction with IPFS? Have you considered sia.tech instead of IPFS?
Thanks for the pointers, I haven't looked at sia.tech. I know about handshake.org but have not looked in detail.
Please don't waste time with Solidity, "smart contracts" and other hocus-pocus that doesn't work. Unless you are looking to raise money - then sure, VCs love the jargon.
For decentralization I would advise you to look into https://github.com/fiatjaf/nostr - very simple approach that should scale without any problems.
Shouldn't the decentralized infrastructure be built in parallel with the UX? First, "decentralized" itself is a big magnet for new users these days. Second, if The Cloud wants to ban you, it'll be a race against them.
I think it would dramatically slow down development and iteration. Getting shut down early on is a much smaller risk than failing to build a compelling experience. (Relatively) few small projects get shut down. Almost all small projects fail to develop a compelling experience.
But yes, I agree in general that decentralization work should be done in parallel. But IMO not on day one.
I think Slava's approach is the right one. Building a social network is risky. Most fail. Building a decentralized social network is even riskier and the right way to do decentralization is still an open question. Better to tackle one problem before the other and since a lot of decentralization problems are only going to be apparent at scale it's better to get the social network side working first before focusing on decentralization.