September 17, 2018

So much to say, so little time

We know everyone is anxious for the 0.6.4 release with garbage collection and it is close. A couple of changes are being wrapped up on the RED wallet and then the final nails will be hammered in on 0.6.4. Thanks to @bitbegin and @qtxie for all their work in those areas.

It's amazing to have @dockimbel walk you through a log analysis and how some debugging was done for GC, inner details of func spec caching, and preview some features in the new GUI console. Even better, he walked me through them in person. That's right, he and @qtxie are here in the U.S. for a deep dive of business and technical work. The days are long, and the coffee is flowing, but we are Red-powered.

Thanks to @lucindamichele for getting the news flowing regularly, and now on to her weekly report.

Last Week In Red


Tell us about yourself and what you'd like to see Red become! Over at https://gitter.im/red/red we have a few questions for you. They're also at the bottom of this message.

More of your input and questions go into documentation: this exchange on Gitter https://gitter.im/red/help?at=5b9813e5728ddf02829371bc prompted a further fleshing out of ways block elements can be accessed: (1) using slash and a numeric index; (2) treating the block as a key/value store (these in addition to originally defined comparative functions like `=, ==, <>, >, <, >=, &lt;=, =?`).

We also saw a number of fixes to the RED Wallet, making it even more stable and flexible in response to data entries. Transactions that are waiting in the pending pool can be edited with greater clarity and simplicity; the wallet now lets you review the amount and address of your transactions.

In Red's Garbage Collection, following the previous week's fixes, some new tests of object recycling were added.

The community project red.specs-public -- a guide to the syntax and semantics governing the language -- added the option to search the repository by datatype.

In his nimble diagramming tool, user @toomasv continues to expand its interactive capabilities, adding a layer for re-sizing of diagram data and further defining shapes.

And here are your questions, go answer them on Gitter, here:
https://gitter.im/red/red?at=5b9af21854587954f99bd32d

1) Do you consider yourself a programmer?
2) Do you consider yourself a software engineer?
3) Do you solve business problems with software?
4) What kind of problems do you solve?
5) What other languages have you used?
6) What is your favorite language, and why?
7) Is "progammer" or "developer" in your job title?
8) Do you think Red should be for "everyone" (e.g., like Visual Basic)?
9) Do you want to use Red for real work, or just fun?
10) What software do you pay for?

We've seen a lot of great responses so far, which tell us about how are people using Red, who they are, which will help us prioritize features. Keep 'em coming, and Happy Reducing!

September 10, 2018

A quick note, and recent updates

More to Come


It's been quiet here for a while, but busy as can be on the development and planning sides. We have new web sites ready to be filled with content, and all this blog content will transfer. On the PR side, Lucinda Knapp is helping us get organized, and get more regular announcements out. They'll be brief, recapping recent work and notes of interest from https://progress.red-lang.org/ as well as Gitter and other community channels.

We have a lot to talk about, and hope to do that soon. If we could just focus on development, things would be much easier. Our focus, as planned, is on the blockchain aspect and C3, but we still need to fill the gaps in the core to support that. And we have to build a business so it's sustainable. The token sale was a huge success but, in spite of that, we are subject/victim to crypto volatility. Do the math. Plans made in January had to be adjusted. Heck, plans made a week ago had to be adjusted. The token sale also came at a huge cost in other obligations. Things we might call distractions. It wasn't just "Here's a bunch of ETH, now go and do what you really want for a year." If only that were true.

There's a solid core team, support from about a dozen people in a semi-official capacity, and we have a great community. As an open source project, we live or die by that community. Otherwise we could just build what we want, and provide dev and consulting services around that. But we want to change the world. We want to help fix what is broken in software development, all while paying our own bills and eating regularly. To do that, we need you. Every little bit helps. While we need a couple more deep, experienced system-level coders (point them to us if you know any), almost anyone can contribute in some way. Reach out. Tell us what your skills are, what you're interested in, how you're using Red, or specific roadblocks you hit with it. "I need Full I/O" is not specific. ๐Ÿ˜ถ Specific is important, because if you are trying to use it for something, that means you have needs and skills in that area. And you're probably not alone.

Our huge thanks to the community leaders, those working on tests and documentation, and experimental projects and research. There is a lot going on, and we're working hard to make things happen that are really worth announcing. 

Happy Reducing!

Last Week in Red


New and notable in Red development: Numerous fixes in garbage collection, addressing crashes both with the recycling of red-symbol, and on macOS after allocating virtual memory. Quick-test.r saw a change, adding a precall. On the Docs side, the percent! datatype was committed by @gltewalt,
applying percent! to typesets number! and scalar!, and it has been added to SUMMARY.adoc.

And among Red community projects, Gritter, a Red Gitter client, has seen feature updates including the mapping of antecendent post-time periods."Starting to be useful," writes @rebolek. In an update to the README.md of OTP/ssword, @planetsizecpu notes that the otp generator is dependent upon
user selected parameters for its strength, meaning it's on the user to determine how strong that password is.

June 11, 2018

RED Wallet: the tiny, simple, fast and secure wallet!

We are proud to announce the release of the first alpha of the RED Wallet, our secure wallet app for the Ethereum network! The source code was released more than two months ago, and since then, the wallet has been used daily by the Red Team and contributors. We are now providing prebuilt binaries for easier access by the general public. The RED Wallet is one of the most secure crypto-wallets in the world, as it requires a hardware key to run. The main features of the first alpha release are:

  • Secure ETH and RED token transactions.
  • Support for the world's leading hardware key: the Ledger Nano S.
  • HD derivation path support: access up to 50 public addresses with the same key.
  • Fast address loading.
  • Fast balance retrieval (thanks to nodes provided by the Red Foundation).
  • Fully open source on Github.
  • Runs on Windows 7/8/10 and macOS 10.1x.
  • Only 269 KB (on Windows), no installation, no setup, no external dependency!
  • Tiny wallet source code: ~500 LOC of Red (plus ~110 KB of Red libs).
  • Custom USB drivers for hardware keys, written in the Red/System DSL.
  • Easy binary checking service to verify that your wallet app is a legit one!
  • Source code under audit by third-party security experts.

The RED Wallet can only be used with a hardware key (currently only the Ledger Nano S, other models will be supported in the future). This provides the highest level of security you can currently have, as the private key is stored in a secure element inside the key, and never leaves it. Signing transactions is done by sending the data to the secure element, visually confirming the target address and amount to transfer. Then the secure element proceeds with the transaction signing inside the hardware key. Once your transaction is signed, it cannot be altered in any way. This means that the hardware key is the weak link of our wallet (after the user, of course ๐Ÿ˜‰), rather than the wallet code itself. Even if the wallet app is compromised, the hardware key and visual checking, provide the ultimate protection. If the user verifies information correctly on signing, a compromised wallet app cannot route your tokens to a corrupted or incorrect target address.

Here is a video showing how the RED Wallet works: (shortly after posting the video, we realized a late edit duplicated a section of audio. We'll fix that as soon as we can.)


Download the RED Wallet application




Just click on the executable to run it (extract the .app file first on macOS), no installation or setup process required. Plug in your Ledger Nano S key and enjoy a smooth and simple experience!

We are looking to provide more options to retrieve the app such as Homebrew support on MacOS or chocolatey support on Windows.

For Linux, we have working USB drivers, but Red's GUI support (using a GTK backend) is not yet capable-enough to run the app. We are looking into a fallback command-line UI in future releases, which will allow easy transaction scripting from the shell or other apps.

If you want to check if your RED Wallet binary has been tampered with in any way, you can simply drag'n drop the wallet executable on our binary checking service. If it's legit, the screen will turn green. If it turns red with a warning message, please notify us on Gitter or Twitter at once.

Only download the RED Wallet app from this page, do not trust any other website for that.


Get a Ledger Nano S key

You can order a Ledger Nano S key from the Ledger site (or just click the image below):


We also plan, in the future, to offer a customized RED version of the Ledger Nano S key. Stay tuned!

NOTE: The RED token contract is not yet referenced by the Ethereum app in the Ledger Nano S key, so be careful with your transactions, as on-key visual checking won't work until Ledger adds RED token support (integration in the Ledger Ethereum app is pending). The address you see, until they update the Ethereum app with RED's information, won't match what you entered in the wallet UI (it will just show the RED token contract address every time). We'll announce as soon as they update the Ledger app.


A bit of history...

The RED Wallet app was part of our plan since last year, as one of the initial steps for introducing RED token use into the Red community. It will facilitate balance checking and transfers between community members, very few of whom have experience with crypto-currencies. It is meant to be very easy and safe to use. (as we have created in this first alpha). We may even integrate it into the Red console, via a console plugin extension.

Since having the first usable version of the wallet a couple of months ago, for internal use, we realized that such an app has great potential. Not just for showing off what can be achieved with Red, but to highlight in the market of wallet apps that we can have lighter, easier to use, and more secure alternatives.

Since then, we have brainstormed about many possible features that other wallets are not proposing, to improve usability, even a possible command-line version for CLI-only users.


Feature list for RED Wallet alpha 2
  • TREZOR hardware key support.
  • Batch processing of a list of transactions (can be imported from a CSV file).
  • Wider ERC-20 token support (using the MEW list).
  • Faster balance lookups (by parallelizing queries).
  • Simplified transaction fee selection.
  • Signed binaries for Windows (macOS binaries are signed already).

Feature list for RED Wallet alpha 3
  • New tab-oriented UI design.
  • Support for cancelling a transaction (Ethereum network).
  • Support for Infura or local nodes, in addition to the Red Foundation nodes.
  • BTC support.
  • ETC support.

Feature list for RED Wallet 1.0

This is our non-exhaustive wish-list for 1.0, we still need to consider the feasability and resources required to support all of those features, so some of them might get postponed to a post-1.0 version.
  • ENS support.
  • Custom HD derivation paths.
  • Linux support.
  • Android support.
  • Block explorer integration:
    • Follow transaction outcomes from the wallet itself.
    • List past transactions for any address.
  • Secure identification of a target address:
    • Contact management (encrypted on IPFS or Swarm)
    • Display identicons.
    • Custom handshake using micro-transactions
  • Command-line version with scripting abilities.
  • QR code generation for sharing your public addresses.
  • Multi-sig support (probably post 1.0).
  • An alternative flat UI skin.
  • A good name. ๐Ÿ˜„

We're noting these features here, rather than keeping them confidential, because we believe users will benefit if other wallets implement them as well. Helping people navigate the new world of crypto safely and securely is our goal.

If you have ideas about how to make the RED Wallet even better, you are welcome to join us on Gitter, to discuss it with the Red user community. If you want to report issues with the current wallet version, please fill a ticket on Github, or drop us a message on Gitter.

The RED Wallet application was made with ❤ by the Red Team. Enjoy! ๐Ÿ˜Š


May 3, 2018

RED token listing

As you know already, the RED token (Red Community Token) has been listed on some exchanges (KKcoin, Xstar, ddex.io), so far using a RED/ETH pair, but those exchanges are small and do not provide a lot of liquidity.

We now have the opportunity to get the RED token listed on a bigger reputable exchange, Bibox, which ranks 17th on CoinMarketCap. In this case, listing approval is a crowd voting process, that will be used for the first time by Bibox. The voting process is described here. A few notable points:

  • Voters get their voting tokens back if the project they vote for does not get listed, so there is no risk for participating.
  • The Red team will reward voters with tokens (ratios to be announced on Telegram groups, see below).
  • There are 7 voting rounds over 7 days. The two projects with the highest number of votes in total at the end of last round, win and get listed.
  • The first voting round starts on May 2nd, the last voting round is on May 9th.

The Red team strongly believes that decentralized exchanges, like those based on the 0x protocol, are the future and will eventually replace most centralized exchanges. A 0x-powered decentralized exchange, DDEX, has already listed RED for some time. The Red team still recommends DDEX highly, as it is the simplest, and one of the most trustable exchanges we've come across so far (to use it you need either a hardware key like the Ledger Nano S, or at least Metamask installed). While not perfect, it improves security, and every little bit helps as the blockchain and crypto worlds work toward more security best practices.

We are pragmatic visionaries and, as the crypto-fans are currently, vastly focused on centralized exchanges, we believe that being listed on at least one big exchange would be, right now, useful for the whole Red community.

Every day we work hard to ensure that we are meeting the goals laid out in the whitepaper, both technically and from the crypto and business perspectives. Balancing the allocation of resources, human and otherwise, takes effort. We're making great technical progress, as many of you following us closely, know. The Foundation has also done a lot of work behind the scenes, in preparation for putting RED tokens into circulation in the community.

This new exchange listing will bring balance on the RED token side. That's important, because we also need to support those who supported us during the token sale. Getting a token accepted on a big exchange is a  complex and hard process, which often simply fails. We have put a lot of effort, time and energy into getting RED short-listed for the voting process on Bibox, and then mobilizing resources for maximizing our chances of success. If you think that RED tokens should be listed on a big exchange, you are welcome to join the Bibox users to vote for RED, and get some tokens rewarded for your help (for refunding your voting expenses). The rewarding information might be changing from day to day during the voting process, so you can get the latest info from our telegram groups in English and Chinese.

Thanks to all of you who are helping the RED ecosystem grow up!



April 4, 2018

Sneak peek at Red on Android

Here is a short overview of the implemented features so far for Red/View backend on Android:



The source code for that Android test app is available here.

Implemented features so far:
  • New java bridge for Android
  • Full set of Red/View widgets supported (some still require extra work)
  • Draw & Shape dialects fully supported
  • Compatibility with Android GUI themes
  • Device-independent coordinate system
  • Updated APK building toolchain for targeting API 23+ Android systems
  • Improved ARM backend, support for ARMv7+
  • Android OS support ranges from 5.0 to 8.1 (tested on a Pixel 2)

The new java bridge replaces the old prototype built a few years ago, the low-level JNI bridge has been kept as is. This new bridge is optimized for performance, and allows efficient bindings from Red/System to the Android API in Java.

Those features were implemented in about a month and half in August/September 2017. We have delayed the continuation of that work, as we need to focus our resources on higher priority tasks for now, like Red/C3 and full I/O support. Once 0.7.0 will be out, we should have some resources available to resume this work. As a reminder, the current work on Android is done in a private repository, in order to keep control over the communication about Red on Android, as we want to maximize the announcement effect on that very important milestone. This private repo will be opened to a group of selected developers in our community once we resume the work on it, in order to help with testing and fine-tuning.

About the Tiger demo, it's a Draw version of the famous SVG tiger. It has many complex shapes, so it is particularily intensive to render in realtime, as in the above animation. From what we have noticed so far, it is CPU-bound on most (if not all) Android devices, so the rendering speed varies according to your device raw performance. We did some simple benchmarks with raw Java 2D vector graphics using the same Android API as Draw, Java code performed only 12% faster than our Draw code. This is an excellent result at this point, and hints that we can achieve great performance for 2D rendering in future versions. Here is the same demo running on a Xiaomi Mi Mix, which has a bigger display and is quite faster than the Nexus 5 used in the first video:




Here is a non-exaustive list of features to add or issues to address in order to complete Android backend:
  • Font and Para objects support
  • Menus support
  • List widgets elements have fixed sizes so far
  • Text-list has fixed height
  • Area widget needs to be completed
  • User-defined list widget
  • Camera aspect ratio correction required
  • Camera control
  • Transition effects between panels
  • Fast 2D sprites and scrolling support (for 2D games)
  • Red GUI console support
  • Common hardware sensors support
  • Bluetooth support
  • QR code reading and generation library
  • Contacts database access
  • Intents access
  • Developer keys management
  • Permission system support
  • Extra application types support:
    • desktop widget
    • headless service
    • wearable
    • TV

We are really excited by how quickly and smoothly was this first part of the work achieved, so this bows well for the remaining parts. As you know, we have a very heavy schedule this year, so we really need the full support of the Red community, and beyond, in order to accomplish it all and finally make the tool we all dream about, come true!

March 27, 2018

Roadmap Updates

After our successful token sale, we are making some changes to our old Red development roadmap.

0.6.4 release

We are merging the 0.6.4 branch into master today. There are still some features to add and polish, so we plan to release it in about a week.

We are still considering a 0.6.5 milestone for swapping the REPL and the toolchain thus making the Red console the new Red executable. If we cannot fit the required changes for that into 0.6.4, we will insert a small extra milestone for that before releasing 0.7.0.

Full I/O milestone

This gets higher priority now, as we don't need to rush Android support anymore, given the new funds we have now. We can now proceed in a more logical order which will result in the Android release having much more complete support.

0.7.0 will focus on bringing the port! datatype and with it, async networking I/O and some basic protocols. Work will start on it right after 0.6.4 release. This also means that a 0.7.x could be turned into a 0.9 release, providing a first Red beta version and a shortened path to 1.0. That depends on decisions about incorporating the module system and/or concurrency support in 1.0, or in a later version. We hope to decide on that with the help of the Red user community, using the voting power granted by the RED token. ;-)

Android milestone

It is still a very important milestone for Red, even if the work on it has currently slowed due to the big blockchain-related wave of tasks. It is now scheduled to be a 0.7.x release. We should accelerate work on it once new developers have joined the team. A new blog article (later this week) will provide a sneak peek at Red's current Android capabilities and what is left to do in order to complete it.

Red/C3

We are still working on combining the Red core roadmap and the Red/C3 roadmap and allocating resources adequately on the different branches of the whole project. So far, the Red/C3 roadmap (as described in the whitepaper) remains unchanged.

The first milestone in the Red/C3 roadmap is:
Q1 2018:
  • Ethereum node wrapper for Red Dapps (alpha)
  • RED wallet Dapp (alpha)

We are glad to announce that we are finalizing those tasks, and will be releasing the wallet app (as alpha) next week! The wallet currently supports only the Nano Ledger S hardware key (no software keys support for now). More info about the wallet app in a blog post next week, including a list of all the features planned for the 1.0 wallet release.

For the Ethereum node wrapper, we have implemented a JSON-RPC library in Red, used by the wallet app. That library will be released alongside the wallet code. It only covers some basic features from the Ethereum node API for now. We plan to vastly extend the API coverage in subsequent versions. Once the 0.7.0 release is out, we could wrap that library code in an eth:// port and provide a nice, human-friendly interface for it. We believe that enabling an easy way to interact with the Ethereum blockchain (and some others later this year), will raise the interest of existing Red coders for the Ethereum ecosystem, and set a new standard for high-level scripting tasks for blockchains.

Last but not least, we are setting up an online Ethereum node, that will be controlled by the Red Foundation, as a backend for the wallet app (currently relying on Infura's nodes) and all future Red Dapps.

We are now preparing to start work on the Red/C3 compiler first alpha, which is planned for release in June. After that, during the summer, we will review the next steps in the roadmap and eventually adjust them according to the feedback from users, how fast we can move Red/C3 to a 1.0, and the state of needs in the crypto world by then.

Red/Pro

Huh...what? :-) Yes, you read it correctly, we, at Fullstack, are cooking a great new product for Red users which should be our first commercial product. At the moment, I am directing Fullstack's key resources to work solely on the open source Red and Red/C3. Work on Red/Pro is postponed to the second part of this year. There will be more info about what Red/Pro is in a future blog post. ;-)

Until then, you can help us test the new console and features of 0.6.4 before the new release, you are welcome to report issues in our red/red or red/bugs rooms on Gitter.

Cheers!

March 12, 2018

Red Foundation news

We set up the Red Foundation structure at the beginning of January in Paris, France. The Red Foundation is kindly hosted by the EPHE, at the Human and Artificial Cognition research unit led by Franรงois Jouen (author of the famous RedCV framework, among other image-processing related projects for Red).


For a brief overview, the Red Foundation structure is composed of several teams:
  • an administrative team: 
    • Nenad Rakocevic, President
    • Francois Jouen, Vice-President
    • Azouz Guizani, Treasurer
  • an operational team, led by Gregg Irwin, and composed of regular members. Peter W A Wood is the first member, and will be followed by more in the future.
  • honorary members, who act as advisors.

The role of the Foundation, as explained in the announcement article and in the RED whitepaper, is to manage the whole Red open source project, and set up a new economic model for open source projects using the RED token. In order to achieve that, all copyright holders in the Red codebase on Github will be asked to transfer their rights to the Foundation. As Nenad is the copyright owner of the biggest part of the source code, he will be the first one to do so (resulting in changing the copyright in the source files headers and license files).

The tasks the operational team is also working on currently, are:
  • a website for the Foundation, featuring:
    • a blog platform where regular reports will be made.
    • full information about the RED token (usages, reward rules and amounts).
    • contributing task bounties for the Red community (paid in RED tokens).
  • defining the rules for retro-distribution of RED tokens for past contributions (since the opening of the Red github repo in 2011). We will proceed with the distribution as soon as the rules and correct amount of reward tokens are decided. This needs the list of contributions and contributors to be gathered.
  • defining the decision processes in the operational team.
  • defining the rules for membership of the Foundation.
  • managing the re-design of the red-lang.org site and moving it to a new platform.

All those tasks and their results will be published on the Foundation website, for the sake of information and transparency.

In order to absorb all these new tasks and the extended roadmaps for the new branches of development in the Red programming stack, we are recruiting new collaborators (non-exhaustive list):
  • a Content and Marketing Manage
  • a Community manager (to help Gregg)
  • devops lead (for deployment and infrastructures management)
  • a low-level system programmer (to reinforce the core Red dev team)
  • an Android system programmer
  • a Win32 system programmer (for maintaining the Windows backend)
  • a Cocoa system programmer (for maintaining the macOS backend)
  • a GTK system programmer (for maintaining the Linux backend)
  • a QA engineer
  • a Security Expert (for addressing the AV vendors issues and other security aspects in the project)
  • a Tokenomics Expert (if such rare bird even exists ;-))

Some of those jobs are already being filled as you read those lines, whilst it might take longer to find right match for others. Most of those jobs will be handled by our supporting company, Fullstack Technology, on behalf of the Foundation. We will post the job descriptions asap.

In addition to that, the Red Foundation is searching for partners helping it fulfill his vision of simplified programming solutions for humans, especially in the blockchain industry. Discussions are undergoing already with some potential partners, like the NEO council, or Enuma, a leading blockchain services company in Hong Kong.

The Foundation will set up a monthly report on all its activities, published on his website (under construction).


March 11, 2018

Red, Rebol & Carl

Another goal of our trip in California was to visit Carl Sassenrath, creator of Rebol, and spiritual grandfather of Red, as Red is the offspring of the Rebol language.

We had a great time with Carl and his wife Cindy, discussing Red and Rebol syntax & semantics, the blockchain industry, smart contracts and the opportunities it presents for our technologies, while enjoying a good Italian restaurant and excellent red wine (selected by Carl, of course!). Carl was particularly interested in understanding more deeply how smart contracts work and how they are currently implemented using the Solidity language. We walked him through the complete source code of the RED token contract, commenting on pretty much every line of code in it and discussing the needs and possible improvements a DSL like Red/C3 could bring over the existing tools. It seems obvious that we could make a huge difference in that domain, given our human-centric approach to software building.

Another aspect that got Carl's attention, was the tokenomics we are setting up for our community of users, using the RED token. Carl read the whole whitepaper (he found it well-written), and was excited by how we could make the community grow, delegate more control over the projects to the community using the voting power, and increase the contributions by leveraging the token, as a reward model for useful contributions.

We were invited to stay at Carl's place, as the discussions lasted late into the night (many thanks to Carl & Cindy for their kind hospitality). At our morning breakfast, we were delighted to hear that Carl accepted our invitation to join the Red Foundation as an honorary member, which means that Carl will be watching our work both on Red and on the Red/C3 DSL, bringing his unique experience and advice on building languages and dialects. As we are still setting up the Red Foundation operations and teams, we will give more information about our collaboration with Carl in later reports from the Foundation. In addition to that, we asked Carl to kindly free the Rebol/SDK (which is something Carl was already considering, as it is not sold anymore), so that Red users could encap their own toolchain binaries if they want to, without having to purchase it. Carl announced on rebol.com that it will soon be unlocked, and provided for free to all!

For the old timers from Red and Rebol community, yes, it means we are on a course to finally join forces and build the dream team we've all wished for over these many years! ;-)

Next article will cover the current state of the Red Foundation and the related on-going tasks.

March 10, 2018

Red in San Francisco

For those eager to get some fresh news from Red, here are some great news items that we are sure you will appreciate a lot. As there are many different topics to talk about, we are splitting the news over several articles that we will publish over several days. This is the first part.

Together with Gregg Irwin, the Red community leader, who joined us from Idaho, we had a memorable time in SF, and the trip was successful beyond our wildest expectations! The goal of the trip was to attend the GoBlockchainConnect conference, the first big conference connecting the Asian and North American blockchain industries. The conference was promoted as bringing together developers, blockchain companies, and investors. More than 1'000 people attended.

Such events are really good for getting the pulse of the crypto community first hand, learning about the state of art in this emerging industry, and connecting with key people, including projects like NEO, and companies like... Google (yes, you read it correctly...more info about that below). ;-)


One of the best sessions we saw was Riccardo Spagni, lead developer of Monero. He had good things to say, and presented himself well. We learned, very quickly, that there is a wide gap in the blockchain space between those who have real substance in product or knowledge, and those who don't.

We had a chance to pitch Red/C3 project to Charlie Lee, Litecoin's creator. He found it promising and asked if Litecoin's VM could be supported. As Litecoin is using an instruction set compatible with Bitcoin's Script, he was glad to hear that such support was already on our roadmap.


Red team and NEO team (Da HongFei and Johnson Zhao)

We also booked a meeting with NEO (a Chinese competitor of Ethereum, basically) at the conference. When we met NEO's team, including Da HongFei, founder of NEO, and Johnson Zhao, their Global Development Director, it went so well that they asked us to attend the NEO DevCon in SF two days later, and have Nenad on a panel about smart contract programming. That panel was a resounding success for Red. Where NEO plans to support C#, Python, JS, and more for blockchain programming, it was clear that DSLs are what everyone really wants for smart contracts.



Now, about the big "G" company. :-) We were lucky to meet a Google manager and engineer at the GoBlockchainConnect conference, and talked with them several times about Red and our plans for covering smart contracts and Dapp development. They just happened to be the two people in charge of the internal blockchain group at Google, and found Red intriguing enough to invite us for a full demo at Google's HQ in Mountain View! The demo went very well, they were astonished by what Red could do already, and how we leverage dialects (eDSLs) to reduce complexity, especially in the UI domain. It quickly turned into a brainstorming session about the possible applications of Red and /C3 in the blockchain industry, and disruptive potential to traditional markets. This resulted in a further invitation to present Red to a much larger internal group at Google, as soon as we have a working prototype for smart contract coding. Do we need to emphasize the potential of such interest by big G? ;-)

Photos taken at the entrance of Google's offices, taking shots inside is strictly forbidden.

In light of all the new potential in the Silicon Valley, we are planning to open an office in the Bay Area, as soon as possible, and recruit a team there.

Even with the ETH we raised, it's all we can afford in SV. ;-)

It was a long week, with long hours, but well worth it in the end. We learned that Red is in a very solid position, and because we're able to move quickly, our chances of success are good. We have a much longer history than other projects out there, though our blockchain strategy is a new aspect. We have real, solid technology that works today, and that's huge. Our community (growing up over 7 years) is also one of our great strengths, and putting things in motion to make use of RED tokens to thank and reward you is near the top of our priority list.

Next article will be published tomorrow, and will talk about our meeting with Carl. ;-)

January 16, 2018

RED Token Sale Success!

Dear RED supporters,

We did it!

I’d like to thank you, and the entire Red community, for supporting us throughout this token sale process. We know that you've waited patiently for new features and releases while we worked on it. We’re thrilled that so many of you are excited about using Red, the upcoming tools we'll build together, and using RED tokens in the community. Blockchain based "tokenomics" is a new and exciting world of possibilities that we can help create, together.

In the past month, since RED’s debut, there has been overwhelming interest in our token sale. We deeply appreciate that support, from all parts of the world.

We can now confidently embark on the next steps in Red's development, thanks to each and every one of you. The establishment of the Red Foundation and the development of Red/C3 are top priorities, but this doesn't mean all the other work stops. The success of the RED token sale means we can redouble our efforts, moving forward in greater strides, knowing we're on solid ground. Your support means more opportunities for the Red community to contribute and be properly acknowledged. Yes, we have a lot of work and planning to do, but we have a strong, clear vision and deep desire to see it through. The wheels are already in motion and I look forward to letting you know each time we complete a major milestone.

We are so grateful, more than we can say, to have such a supportive (and growing) community around us. On behalf of the entire RED team, I want to share our appreciation for you all, and I personally want to thank each of you for loving and believing in Red.

To Red's future, our future!

January 13, 2018

Registration Special Offer

Dear Red users and followers,

Thank you all for your genuine interest in Red, we greatly appreciate it.

We have received overwhelming requests and a very high number of documents for the registration.

It is the contributions from each and every one of you that makes Red great, and we thank you very much for your strong support. During that time, I was giving a speech at the FINWISE 2018 conference in Macau, as part of our road show for introducing Red to the blockchain community.

We set up strict rules for the acceptation process in order to secure it as best as possible. So we want to take the time to carefully review each provided document.

This is what we propose for those of you who submitted valid KYC verification information before UTC 7:30am, January 12th 2018, and could not participate to early bird round:

    1. We will send you a confirmation email informing you about your successful registration.

    2. You will then be whitelisted (all at once) and be able to buy the remaining RED tokens from the early birds supply, and at the upcoming open round.

   3. For those of you who could not participate to early bird round, but submitted the valid KYC before UTC 7:30am, January 12th 2018, and who will be buying during the open round, we will refund you 10% of the ETH amount you sent (you will be keeping all the RED tokens you will get), effectively giving you the same conversion ratio as during the early birds round.

We hope this is a satisfying solution and will make things right for those who could not participate yesterday.

The open round starts on UTC 8am January 16th. Get ready! ;-)

January 9, 2018

RED: here we go!

After long weeks of hard work, we are finally ready and happy to announce the opening of the token sales! We had to rename the token to RED (all caps), as an RCT token was deployed by another project a few days ago. Its purpose is still unchanged: powering the decentralized apps and Red community tokenomics!

This process will be held starting from January 8th to January 31st 2018, in three stages:
  Private Angel Investors       : Jan  8th - Jan 11th
  Early Bird round              : Jan 12th - Jan 15th
  Open round                    : Jan 16th - Jan 31th
The total fixed supply of RED tokens is 200,000,000. The allocations are:
  Private investors             : 10% (20,000,000) with a 3 months lockup period.
  ICO (earlybird + open rounds) : 30% (60,000,000)
  Red team                      : 15% (30,000,000) with a 12 months lockup period.
  Red Foundation                : 35% (70,000,000)
  Marketing/Strategic           : 10% (20,000,000)
Exchange ratios with Ethers (ETH) are set as:
  Private Investors             : 1 ETH => 3400 RED
  Early Birds                   : 1 ETH => 2750 RED
  Open round                    : 1 ETH => 2500 RED
Only Ethers are accepted, with a minimum of 1 ETH. Private angel investors also benefit from a 20% unlocking at the closing date of the token sales process.

In order to participate, you will need to go through an online registration process (KYC), and provide the required credentials. Citizens of countries that have banned or posed heavy regulations on such token sales are not allowed to participate.

For more information about the token sales:

This is the culminating point of many months of hard work and preparation. Many thanks to the teams and partners who have worked over the clock to make this happen. This is the dawn of new era for Red and its community of contributors, users and followers. Help us make it happen now!

Go RED!

January 3, 2018

Overview of Red development history


This video shows a fast-paced timelapse of the Red source code changes in the main repository over last 6 years, 9000 commits. You can see the avatars of all contributors, flashing commits on the files over time.

Here are a few stats showing the changes between Jan 1st 2017 and Dec 31th 2017:
  • Github stars: 1214 to 2970
  • Github programming languages ranking: #34 to #22
  • Page views on red-lang.org: 1.06M to 1.65M
As you can see, 2017 has been a great year, with interest in Red growing for some stats, faster than in all the previous years put together!

Short history of Red

Given that many newcomers arrived in Red community in the last two years, some might be confused about past Red history and timeline, so I would like to write it down now, and add some comments in retrospect on some of the choices made in the past.

The Red project was officially launched in March 2011, with the first public announcement and the release of the version 0.1.0, which was developed in 3 months. That early version provided a fully working Red/System toolchain, with a compiler and linker, all in 60KB of source code. That was just for Red/System, the low-level DSL of Red.

The Red language had different goals at that time, it was meant to be a statically typed sub-set of Rebol, with static scopes and no dynamic binding. That Red would have been only compiled, so no interpreter, and would eventually had a REPL after 1.0, once a JIT was available. Given my old work on an experimental Rebol clone in C a few years ago (implemented in 9 months), I estimated that a 1.0 for such Red could be doable in a year. Such a version would only support Windows and x86 architecture, would have most, but not all of Rebol datatypes, no DSL, no GUI nor floating point support.

During 2011, a community of users and followers started forming around this early Red version, the daily interactions with the community had some influence on the goals I had initially set for Red, and at some point during that year, I realized that what I really wanted was a more dynamic language, closer to Rebol, rather than a crippled static version. I decided then to trace a new longer road to a different design for Red, more in line with my personal desires and community expectations.

The scope extended as we kept adding new features (sometimes initiated by contributors), like ARM support, floating point support and Parse dialect. We then replaced the early low-level lexer with a much more capable version using Parse. The community was pressuring for a more "production-ready" version, which meant adding more features, like extra datatypes, postponing the 1.0 milestone further away up to 2014.

I have been working full-time on the project since 2011, and invested all my personal money to fund it, helped by individual donations from community members. Frankly, without those extra donations, I wouldn't have made it. In late 2013, I was contacted by a China-based VC (Innovation Works) who was interested by Red project. They offered me the chance to join them in Beijing. I initially politely refused, as I thought that doing so would consume too much time and accepting investments never has a guaranteed outcome. But thinking more about it, I also considered that raising a seed round would allow some talents in the community to work full time on Red, speeding it up. So, I accepted the offer and relocated to Beijing in 2014, settling for a new life there.

Red in its command-line form was not good enough to attract any investor, nor make any good business plan. So I made a major decision to incorporate the GUI module in the roadmap as soon as possible. The original plan was to only add it after Red had reached version 1.0. I also thought that Android support would be a key element for Red's future, so I also move it forward too. It took me about 7 months to raise a seed round, and 4 more months to effectively get the money into the bank account of the newly formed company in mid-2015. Work on Red during that time went more slowly. It never stopped though as we could hire our first developers (using a loan) and the number of contributors from the community was increasing.

A new roadmap was set and a 1.0 was planned for 2016 focusing on Android GUI support. Though, the early prototype on Android showed that developing a cross-platform GUI engine starting with Android (as we wanted it asap) along with the VID DSL was not a good way to achieve it, as the development cycle with Android was too long, and debugging at low-level there was very limited and painful. It was way more convenient to do it on a desktop OS like Windows, which was also the platform of roughly half of our users. So we switched the GUI development to Windows first, as it would be much faster to design and polish the cross-platform parts there, then make an Android back-end for it after.

The GUI engine with the VID dialect and back-end for Windows was released in early 2016. We initially planned only a minimal support and just a few (5-6) widgets for the Windows back-end, but the community wanted more (and still does). At the same time, we were also working in parallel on a Red IDE engine based on Scintilla. We needed more widget support, so we spent extra months doubling the initial number of widgets and polishing the features of VID, Draw dialect and View engine. The Scintilla IDE prototype was not as promising as we expected, some limitations with Scintilla were disappointing to say the least. They included awkward Unicode support and UI limitations. A Red GUI based IDE was a better option, allowing us to support any feature we could think of. We ran out of resources for such a side-project, so we put it to sleep until we can fund it (hint hint, the ICO would help there a lot too!).

After the initial GUI release, before we went back to Android support, we had to do some promotion about Red and our new shiny GUI system, in order to increase our userbase  (growth is a constant concern for VC-backed startups). Though, the competition was rough, as the new state of the art (on the web) was reactive frameworks which were providing a more powerful and simpler way to operate GUIs. Such reactive GUI was also something I had on my wish-list since 2010 for Red, and it seemed like the right time to add it, so that's what we did and released it in mid-2016. That enabled the production of some pretty impressive demos I think, for a cross-platform native GUI system.

We went back to Android development after that, starting by adding a preprocessor to Red lexer, in order to move a lot of costly work done at runtime to resolve Java method signatures, to compile-time. This work consumed around a couple of months, especially as we also took that opportunity to add an experimental macro system. The preprocessor is currently used by the Red runtime to reduce code size, though, we late figured out a better way to handle the Java method signatures  without relying on the preprocessor. So, we could have saved some time there, even if it's always easier to come to such conclusion when looking back in time.

As we continued on Android support, we stumbled upon new unexpected issues. All the features added in the last releases significantly increased the runtime size, resulting in very long compilation times. Moreover, the GUI system and newest object features broke the ability for the Red compiler to produce functioning shared library files for Red programs (Red/System shared libraries were fine, it was a limitation of the Red runtime library and compiler). We then decided to launch the "libRed" branch, in order to solve all those issues by enabling the compilation of the Red runtime as a shared library in two different forms: one is libRedRT, used only for speeding up the compilation process, the other is libRed, which provides an external API for embedding Red into external software (which was on our todo-list anyway and in the Red initial goals). That work took more time than expected, roughly 7 months, as I had to travel across the globe many times (for personal reasons) going offline for a total of 2 months during that period, which made it harder to properly focus on some of the complex issues that needed solving. That is where we lost the most time in the last couple of years, although the macOS GUI branch was still advancing at the same time in parallel.

After macOS release earlier this year, we could finally continue the work on Android, and guess what, we could develop a GUI backend on par with Windows one in about a month and half only! All the preparation work done before was paying off in the end! Still, that is not enough for acceptable Android support, as mobile devices have many features which need first-class support, and we are working on them for 0.6.5 release (delayed by the ICO preparations and process). We will provide more info about Android support very soon.

Another important consequence of adding GUI support for macOS, was the need to have a GUI console there too (identical to the Windows one), as we have great plans for the GUI console itself. As a side-project, we started working on a new GUI console engine in early 2017, replacing the low-level OS-specific Red/System bindings with the Red/View engine, enabling cross-platform support out of the box, and adding some key features we needed on the Red roadmap, like rich-text support. Those features are available in our 0.6.4 branch, and will be part of the next release shortly after the ICO (though probably after Chinese New Year in february).

One thing I have greatly underestimated during all those years (especially at the beginning), was the amount of time that would be spent interacting with the community, as I tried to be as present as possible online to answer questions, welcome newcomers and help them get started. My public posts are just the tip of the iceberg, as many people just contacted me on direct channels (email, private messages on AltME, Gitter, skype, ...), and that consumed a lot of time too. But, I think it was a necessity anyway, just unaccounted for. Nowadays it is much easier for me, as we have community managers and many other members who are doing a great job handling newcomers, wave after wave. Another thing I didn't consider at the beginning was also how much impact and influence the community would have on the features that we would put into Red (especially pre-1.0). As old-timers from Rebol community were used to have a great amount of feature available out of the box, they expected Red to be on par with that, often without much concern about the costs involved in supporting the desired features. I think I should have said "no" more often than I did, or just postponing them after 1.0.

All in all, despite the bumpy road sometimes, the current version of Red is better in many ways than what I hoped for in 2011. We still have the option to rename the 0.7.0 or 0.7.1 upcoming milestones to a 1.0 candidate, as they would have all the features we initially planned for a 1.0, though there are pros and cons about pushing the other planned features post-1.0, but I understand that Red users nowadays are more interested in reaching a 1.0, than having a more feature-complete one. We can discuss about that on our Gitter channels.

This is a (very) short version of the Red history, there is so much more to say about it, maybe someday when I will have some spare time, I'll write down the whole thing in a book, including my views on language design, and all the non-tech related side stories. ;-)

Cheers!

January 1, 2018

Answers to community questions


After our announcement, we already answered on Gitter some questions related to this new sub-project of Red that we are launching. The remaining new questions are answered below.


ICO-related questions

Do you have an estimate how long establishing that foundation will take, couple weeks?

We expect it to be officially set up before the end of January (if not delayed by extra paperwork). We are setting it up in Paris, France.

Why choose ICO instead of traditional funding schemes (Patreon, donations, etc)?

That's a good question. In 2015, we already raised a seed round for the company supporting the development of Red (Fullstack Technologies), though that is far from enough in order to move faster, as the scope of the project keeps growing. Individual donations were enough 5 years ago, when the project was in its infancy, but that level of funding is not capable of sustaining the project in its current form since a long time.

What is plan B if the ICO is not successful?

In such case, Red/C3 will drop low in priority as we won't be able to fund the work on it, and the Red foundation will have no mean to operate and help Red project and community. We would then focus on our core roadmap and unroll our business plan for the Red core technology only. The ICO is a better path, not just for funding the whole Red project further, but because the blockchain market is a big new opportunity for the Red stack, and we should seize it in order to grow up faster and much bigger. Moreover, introducing a token-based economy in the Red platform would open many new business opportunities, both for our company, and for the Red users.

All other ICO-related questions will be answered once we set up the landing page for the ICO, with the published whitepaper and adequate communication channels. All that is under heavy work right now, we should be ready in about a week from now.


Blockchain

Any plans to run a private NEO blockchain?

That is something we are considering, yes. Though we have many other possible choices. We should meet with the NEO council in 2018, so we will be able to investigate that option deeper with them.

Are there plans for Red to support IPFS?

Clearly yes. That can happen just after 0.7.0 release with full I/O support, though this could be contributed by the community (with sponsoring from the Red foundation), it doesn't need to be implemented by the core team.


Red/Core

How is Red sustained, who currently supports it?

Red is sustained by its supporting company, Fullstack Technologies, who received a seed investment in 2015, and by contributors on a daily basis. Previously, Red was funded by my personal money and donations from users.

Is stuff like concurrency also required to reach 1.0, and be used on blockchains? 

We plan to have a form of async tasks support for 1.0. There are several models we could use, Actor is our prefered model so far, but the final choice is not done yet. For parallelism, that will be for a 1.x.

Is interop with other mainstream libraries/languages (java, python, c#, go,...) planned?

LibRed can be used for that. We have a few bindings already. For Java, we have built a bridge a few years ago. That bridge has been improved in our new Android branch (currently private). For Python, Go and other languages, it's up to the community to plug libRed there, if needed.

You said that the current Red roadmap will be delayed by a few weeks. You don't think it will be much more with all activities created by this big move?

We plan to resume on our normal roadmap as soon as the ICO is done, so by finishing and releasing Red 0.6.4. The new branch of development will have its own roadmap and dedicated resources (hopefully paid by the money raised through the ICO). My personal time will be split between the core parts (including Android) and the blockchain branch.

Giving recent announcement, it seems that Red drifts further and further from initial idea of Carl. Building blockchain tech without proper GC, or 64 bit support and just basic I/O. And it's worrisome that "full-stack language" and its community may lock itself in one niche. Can you comment on that?

On the contrary, Red goes closer to the original idea of Carl, of a "messaging" language and distributed computing through IOS reblets (the X-internet), as explained by our announcement article. The blockchain technology helps improve such architecture, by allowing it to operate in a decentralized way. For the rest, the GC branch is almost finished and should be available in 0.6.4 release. 64-bit support is not a top priority right now, as 32-bit apps can run on all our current target platforms, so it is more of a convenience for some users. We know that some OS vendors are planning to restrict their platform, so we will set up a path to go 64-bit, though it will take some time to get there. For the record, "blockchain tech" and GC/64-bit are totally unrelated features and are not even on the same roadmap.

About "locking itself in one niche", that makes no sense, the announcement article says "in a new branch of the Red project". So the project is expanding to cover more domains, and not restricting itself in a niche.

Following both planned Red roadmap and doing Red/C3 in one project... isn't it too ambitious?

As explained in previous answers, Red/C3 is a sub-project of Red, with dedicated resources. There is a great opportunity for Red in the blockchains right now, targeting smart contracts and Dapps. Red is a great fit for the needs in that market. That is a great opportunity to expand Red userbase and spread Red around.

That is all for now, if you have more questions, please ask them in red/red or red/blockhain rooms.


Happy New Year to all the Reducers in the World! 2018 will be an exciting year for all of us! ;-)

Fork me on GitHub