cydrobolt

haha :)

Also useful for making easy to remember links to often-used resources

Haha, I totally agree. Reminds me of this: http://www.willa.me/2013/11/the-six-most-common-species-of-c...

Minimalist in regards to its design, perhaps not the code structure :)

In contrast to other projects such as YOURLS, Polr tries to be minimalist by avoiding heavy graphs or unnecessary bloat.

Agreed. Using Bitcoin would definitely help make it resemble cash, however, this could potentially be less convenient. Venmo is more popular among students, especially on university campuses, so the idea was to make it easy to adopt among friend groups, not specifically to guarantee the transfer of funds.

Agreed. Although it has none of the guarantees of cash, it would also be more difficult to steal (as the authorization can be revoked). This is more similar to a bank check than actual legal tender.

(potential drunken party game: throw 10 paypyruses and the first to cash in gets the money)

Paypyrus being based on Venmo, we cannot guarantee payment if the bill creator decides to revoke our authorisation or delete the bill. This is due to Venmo's friend-to-friend model, which we are based on. No bot accounts are allowed, so the money is never placed in our hands. It is a direct P2P payment between friends, presumably.

This would be analogous to a bank check rather than a paper bill. Since it is not legal tender and there is no middleman in the transaction, it could not be spent (or stolen) as easily as a dollar bill.

Yeah. Right now, it is largely based on trust. We're hoping to implement some kind of one-time "seal" and new token that a user can verify after receiving a bill to ensure that someone else can't activate it with a picture or by saving the token. That obviously comes with the downside of making it more difficult to transfer.

As a proof of concept, and being based on Venmo, I think it is and will be largely based on user trust as long as the bill creator keeps the funds (Venmo allows no bot accounts).

Yeah. The speech recognition is really dependent on the placement of your mic, background noise, etc. We're using wit.ai's recognition engine for this, but we could also base it on other libraries or APIs. Perhaps we can figure out a way to optimise the detection in the future.

I can't agree more with this headline. I can concede that IRC isn't the most modern of technologies, but it is effective and well-developed at what it does. There is a FOSS ecosystem that can be achieved with IRC, which cannot be achieved with Slack. As a FOSS project, you can commit to only using free and open software when you also use IRC, as software such as atheme or charybdis are all open.

Additionally, Slack is more privatized, with a less opportunities for enhancement (e.g IRC bots, IRC webchat, many clients). All users also need to sign up prior to use, which is just simply not viable. IRC manages large influx of help-seekers or project members well with its op-voice-user and ban/quiet system, allowing for channel operators to handle the high amount of users without a problem.

On the other hand, Slack fails at all of these points, as it is intended for internal team usage and struggles with this specific usecase.

Furthermore, most FOSS contributors are also not contributors to a single project only. For instance, I personally contribute to a variety of FOSS projects, and it is extremely easy for me to coordinate with all of those projects simply by opening a new channel on my freenode or OFTC network in my IRC client. Slack lacks this, requiring a new tab for each project and really lacking support for FOSS operating systems such as Linux distributions, a problem that is likely not going to be fixed due to its closed-source one-client structure.