Episode #015 – ARK V2 Compilation Show (ARKv2 Mainnet Upgrade Date Is Nov 28 2018!)
The fifteenth episode of the ARK Crypto Podcast is here! The buzz behind ARKv2 is afoot, and there are a lot of new people getting acquainted or re-acquanted with ARK as it completes the development cycle and launch of the new core code onto the ARK mainnet. Users like you won’t need to do anything regarding funds- simply upgrade to the new wallet as needed. There are no special steps to “keep your funds safu.”
In this episode we dig into the podcast vault to bring you the relevant information you should know about that has been discussed on previous episodes. With this compilation, you can catch up on ARK without breaking a sweat. The only ARKv2 content not included here is in episode 13, which is quite recent. For more catchup, or to learn more of ARK’s many achievements, check out the community resource ArkTimeline.com.
The mainnet protocol upgrade is occurring on November 28th.
For more episodes & insight into all things ARK, follow us on facebook, twitter& instagram or subscribe with your favorite podcast app. We are currently live on Soundcloud, iTunes, Stitcher, Google Play Music, and Spotify. As always, thanks for listening!
This episode is hosted by Justin Renken.
Justin Renken: Hello crypto-land. I’m Justin. It’s Friday and this is the Ark Crypto podcast, episode 15. Well, we finally live in a world where we have a date for the pending Ark Core v2 Mainnet protocol upgrade. This has been well anticipated for a long time and everyone is very excited to see the new code hit the Mainnet.
Justin Renken: If you heard the good news and joined up with our strong community, welcome. Here are a couple quick things you can do. Don’t forget to subscribe to our sub Reddit at reddit.ark.io, our Twitter account at twitter.ark.io, and our Slack, where you can easily and quickly talk to other community members, delegates and team members. That’s at slack.ark.io.
Justin Renken: This week, what we’re going to do is a compilation show. We’re going to talk about all of the Ark v2 content that we covered in 14 episodes of the Ark Crypto podcast. It’s a lot of fun to talk about Ark in these podcasts and this week we’re going to cath you up on all the relevant v2 information that you need to know. Don’t forget, the Ark Crypto podcast is for education and information only and we will not ask you to purchase Ark or make investments of any kind. This is not investment advice.
Justin Renken: Let’s listen to Ark v2 content from episode one. Enjoy. Section four is called Ark v2, the Next Frontier. In order to prepare for the next generation of deployable delegated proof of state block chance, we understood very quickly that we had to thoroughly rethink the legacy code and move to our own, completely rewritten from scratch. Throughout the current run of version one and with experience gained during the development of Ark, we have been able to identify several key elements in the core design that could be optimized.
Justin Renken: Now, we embark on a new voyage to completely overhaul the Ark code, as well as the protocol, as a foundation of our ambitious road map. The new Ark-itechture has been completely rethought to decouple delegate forging activity, transaction pool management, and API interface on separate threads. Transactions will need to pass complete simple payment verification on a separate process or server before hitting the Mempool, completely sandboxing the activity of the node against attacks.
Justin Renken: Ark Core v2 is completely configurable, meaning you can adjust the block chain mechanics to your preferred setup. Users are able to adjust block times, number of delegates, block size, customize fees, and set block rewards. This configuration is a living setup, meaning it can be adjusted after your bridge chain is already running. All you need to provide is the block height parameter from where the new configuration will be valid and in use. It will be possible to use your own favorite SQL flavor. It will also be possible to override your own database interface and pass it to the node. Initial internal tests are already showing impressive results with lightning fast rebuilds using SQLite as backend, leveraging the multi-core capabilities on our test servers.
Justin Renken: The security will be hyper-enhanced, using a completely independent transaction pool, responsible for keeping a list of unconfirmed transactions that could be then broadcast data or pass along to the forger to forge a block. Finally, the forging process will be completely independent and self contained. It will be architected in a way to switch communications with other relay nodes if the original relay node is getting attacked or forked. We have designed the relay nodes to be as light and stable as possible, and we recommend these relay nodes if you are building a business over the Ark blockchain instead of a Lite client since it will allow more powerful computation such as complex SPV proof of balance or batch verifications.
Justin Renken: Section 4.1 talks about the new plugin system. The plugin system is awesome, by the way. Ark Core v2 will be split into multiple packages using Lerna to manage development and publishing of those packages. The benefit of this approach is that it’s easier to focus on smaller parts of the whole system in isolation. Each part of the core can be easily replaced by custom implementations. Imagine a Core logger Logstash package that replaces the default logger. All of those plugins are interconnected via the core plugin manager package which functions as a container to hold all the instances that are shared across plugins.
Justin Renken: The plugin manager allows us to provide different bootstrap processes for things like starting a relay node or forging node. The plugin manager accepts two parameters; the path to a folder that contains a plugin.json file and the optional parameter that can contain options like excluding or excluding plugins from the bootstrap process or plugin specific options that are not available from the config file.
Justin Renken: In section 4.2, we’ll talk about listening to block chain events with WebHooks. WebHooks are also awesome, by the way. WebHooks implementation is a realization of Ark improvement proposal AIP 15. WebHooks enable Ark blockchain app developers to listen to blockchain events in a simple manner by subscribing to events and waiting for callbacks. Polling is just wasteful and inefficient for both the client and the server side. On average, 98.5% of polls are wasted and increase the workload on the server, making WebHooks much more efficient.
Justin Renken: Best practices and happy developers with efficient tools are all part of our motivation to deliver Ark Ecosystem as a platform while providing a stable and efficient base to build blockchain apps. With Ark’s new API-v2, you will also get WebHooks capability that will call and deliver data based on event conditions.
Justin Renken: Section 4.3 talks about the Ark test suite, based on Jest technology stack. Test suites are an important part of any serious development environment. More so with blockchain technologies where each mistake can end up being very costly. Most of software developers are already aware on how hard it is to get full test coverage over different testing phases. Now add blockchain mechanics to that recipe and think about how to test distributed systems. Their mechanics, security, block propagation, transaction management, transaction pool handling, work management, client API. Where to start? With these challenges in mind, we had to pick the right tool that is flexible and powerful enough. We have chosen Jest framework as our base testing framework.
Justin Renken: Let’s hear some Ark v2 content from episode three. Ark.io listens to the community just as much as the community respects and enacts what Ark.io is up to. At the moment, there is no type of contention. You do help me touch on a point that’s coming up soon. Ark v2 hit the DevNet today and final testing is getting set up and everything. Now, when it comes time to put Ark v2 onto the Mainnet, that’s called a hard fork so, they’re going to do a protocol upgrade, they’re going to send the code base to all the delegates. The delegates are going to change their nodes up and there’s not going to be two chains. There’s going to be a chain that lives on, which is the Ark v2 chain and there’s going to be a v1 dying chain of lazy people who didn’t want to update and nobody cares about that chain.
Justin Renken: It’s not going to be something like Bitcoin, Bitcoin Cash, free coins arguments for nine months. No. The delegated proof of stake consensus algorithm really helps facilitate quick decisions on what’s going to go down and then allows a singular direction forward. There’s been cases where Ark.io has been like, hey, let’s do this with the blockchain and the community was like, “If you do that with the blockchain then we’re not going to play ball with that.” They were like all right. Never mind. It’s not like we don’t care and we’re doing this and this is what’s happening. There’s a harmony there and because the number of nodes running is not the same as the number of wallets and stuff, it’s a lot easier to have those discussions, come to those conclusions and figure out what’s going on. Those are also public discussions that anyone can contribute to, which allows anyone to propose an idea. “Hey, we should do this to Ark. It’s a really big change, so we need to talk about it.”
Justin Renken: They submit an AIP then delegates, team and community members can discuss that AIP and decide whether it should proceed on to the next protocol update, whether it should die or whether it should stay on a shelf because it’s a good idea that should be considered maybe at a later time. Exactly. Exactly. That’s exactly right. The freeness of the way Ark has things set up, it allows a case where a group of people can say, “We can do the Ark Mainnet better and we’re going to make a new Ark Mainnet with different changes to it and see if people want to use that as the central …”
Justin Renken: … different changes to it and see if people wanna use that as the central situation, to connect to all the block chains, instead of the current Arch [inaudible 00:10:09]. It’s not impossible, but it doesn’t seem very likely at this time. Yes. You had a question? Right. Okay. The rules of engagement. Can you expand a little, bit on … Yeah. Okay. Got it. Arch v2, being the second version, that means is the first time that we are doing a Hard Fork. It’s the first time that we’re doing a protocol upgrade and asking the delegates to play ball.
Justin Renken: We’re gonna see what happens, but we already have been in talks with all these delegates that are, deciding what’s gonna go down. They’ve all expressed overwhelming support for the Hard Fork. Now, I don’t foresee a specific case, that would cause a contention, like you saw with bitcoin and bitcoin cash. The block sizes don’t matter in delegated proof of state. The delegates run nodes and they increase the blocks. Nobody cares.
Justin Renken: The block times, they don’t really matter, unless it is a proposal that forces more centralization to happen. If somebody was like, “Hey. I want one second block times,” then we would say, “Well, we can’t really do that without sacrificing some more decentralization, and then that might cause a situation.
Justin Renken: These types of things just tend to kind of just die out. When the time comes to actually Fork, some people might not Fork, because they just don’t feel like running a node anymore, or they just didn’t get the memo. It’s gonna create a Fork. It’s gonna create another chain of Arch v1 of people who just didn’t do anything. The exchanges won’t care. Archies don’t care, because these are all really big upgrades and improvements that everybody agrees are upgrades and improvements at the moment.
Speaker 1: Let’s listen to this Arch v2 content in episode six.
Speaker 2: As far as Arch, are you guys … Did you guys build this from the ground up? Is it Forked off of something, or is it, it’s own unique block chain?
Speaker 3: Like I said, it was originally the code base itself, where Arch started on, would be [inaudible 00:12:09] base.
Speaker 2: Okay. Which forked into Lisk. We took their most recent repo at that point in time and we forked off of that. All that code base is going to be deprecated, it’s going away right now. We’re big on our new core v2, which is completely revamped, completely recoded from scratch.
Speaker 3: Yeah. I noticed that actually. You guys have been talking about that a lot. Well, actually I wanna get into that. Can you just kind of real quick, give everyone the elevator pitch in case I have some new people that maybe aren’t familiar. What exactly is Arch?
Speaker 2: Arch is an interoperable block chain and a development platform. It gives everyone the ability to spin up their own blockchain, for whatever they may need it for, while being able to talk to other block chains within the Arch ecosystem, and using other functions in Arch to connect to outside block chains, such as bitcoin, ethereum, litecoin. You can actually issue smart contracts on ethereum without ever touching ethereum, just by using the tools that Arch provides.
Speaker 3: Yeah, as far as Dpos, we are familiar with that. EOS is doing something similar. I’ve seen a few others as well with that system. As far as getting, you know, voted in, how does that work exactly? Is it just standard? Some people do worry, is it actually fair? Are you just voting in your friends, you know and stuff like that?
Speaker 2: Yeah. That’s the difference between a decentralized delegated proof of stake system and a centralized …
Speaker 3: Yeah.
Speaker 2: delegated proof of stake system. EOS is more of centralized proof of stake system, because they’re vetted. They pick who they connect to. They pick who runs the nodes. They also have tunnels in between, connecting all of these nodes, so less decentralized I guess, not quite centralized. With Arch, the way it works is, every single person on the network can vote for a delegate node, a validator node. There’s 51 in the Arch network, that run it. At any point in time, one of those top 51 can be replaced. We have no control over that. Everyone holding the Arch token controls that.
Speaker 3: Yeah. I wanted to get back really quick. We were talking about using … Well, I know you weren’t being block chain as a service, but just saying somebody does essentially Fork, right the block chain, if they need their own. Would that make it essentially? You see so many people talking about transactions per second, this and that all the time. That seems to be a huge buzz word. In reality the fact that you’re, kind of cloning your own block chain and your block chain can talk to itself, does that, in theory mean you could have infinite scalability because you can … If you run out of space, you could really just make another block chain?
Speaker 2: Correct.
Speaker 3: Okay. Yeah. That’s something that a lot of people don’t understand. When it comes to these older projects, you know, everything’s about DAG models now and this and that. In reality, if you use a system, like what you guys have set, the truth it … Well, first of all, the truth of the matter is, is most of these, mom and pop shops might need a block chain in the future, are really not gonna be hitting like Visa or MasterCard TPS anyway.
Speaker 2: Right.
Speaker 3: You know, in the off chance that you do, it’s nice to know that, that’s a capability that you guys have, that we’re not gonna hit a ceiling, we’re not gonna, you know, run into an issue like that.
Speaker 2: Well yeah. Like you said, the mom, and pop analogy … When you put a delegated proof of stake system like ours on a private network, a private server, you will probably never ever need to hit those, kind of transactions per second. Right now, we are pushing for our new v2, we’re gonna be starting at 150 per block, which is like 19 TPS right now. At any point in time, this is delegated proof of stake, it’s great. We don’t have to sit there like a Bitcoin. It takes forever to bring up a protocol or change something in Bitcoin.
Speaker 3: Yeah. It pretty much doesn’t get changed.
Speaker 2: Right. With Arch, all we have to do is push an update to the code, and the delegates upgrade in the background. It never affects any users, there’s no forking involved. If we wanted to bring the transactions up to 250 per block, we just push a code, the delegates can say yes or no. They can upgrade.
Speaker 3: That’s awesome. As far as … Those are the ways you can upgrade it. Now, I do wanna talk about v2, version two, the thing you got going on right now. What are those … What’s different about this, versus what you guys had before? Why is it better, and you know, what can we expect really out of it?
Speaker 2: I know a lot of people are waiting for dynamic fee structure. Most delegated proof of stake models, have a standard flat fee of .1 or something like that.
Speaker 3: Yeah.
Speaker 2: We have a dynamic fee structure already built into the code, and we’re just gonna make it client side. The delegates themselves, can set their own fees for each block. If all the delegates set it at .000001 Arch for any transactions, all the transactions in the network will go through those nodes that actually go that low. If you set it too low, the network will reject it, send it back, and tell you the fee’s a little too low.
Speaker 3: Okay. That fee wouldn’t get lost in the process right? It would be [crosstalk 00:17:11] returned back to you? Okay.
Speaker 2: It’s automatically rejected from the network.
Speaker 3: Okay. On ethereum, I’ve had situations where I’ve been trying to send something five or six times and every single time I send it, I literally loose gas, loose gas, loose gas. Next thing you know, it’s like, you know, “What the hell’s going on here?”
Speaker 2: Yeah. That’s one great upgrade. Of course, the protocols up and it’s already been coded from scratch. We also have multi payments coming through. There’s a lot of delegates in the network that provide services, whether it’s coding, building a project, marketing or something like that. They ask the community to vote them in. As such, they’ll pay out a percentage of their foraging rewards. A lot of these delegates have thousands of voters. They have to send thousands of transactions back out when they pay a percentage to these people. We have multi payments coming up, making it way easier, making their fees even lower as well. Essentially they could send 2,000 transactions in one transaction in a small fee.
Speaker 3: It’s kind of like you got the lightening network for Arch, where you’re, sort of, a …
Speaker 2: Yes.
Speaker 3: You’re almost setting up a bar tab, and then pushing it all through at once.
Speaker 2: Yeah, yeah. That’s similar. There’s a lot of good reading on our blog about the different functionalities that come with v2. Like I said, the dynamic fee structure’s amazing. Multi payments are gonna be awesome. Our AIP 11, which is our Arch improvement protocol, 11, is going to be time locking, and basically setting up for our Arch VM with our smart contracts. V2 brings that as well.
Speaker 1: Here’s some Arch v2 content you’ll find interesting in episode seven.
Speaker 2: Yeah. Arch v2.
Speaker 4: Yes.
Speaker 2: What’s up with that, when v2?
Speaker 4: Yes. That’s a good question. I don’t know if you were in the conversations that we were having yesterday. There were pretty extensive conversations with the team and the delegates and just kind of discussing the sense and the feeling in the community and kind of how things are going.
Speaker 2: Sure.
Speaker 4: Things that we could do better. In that conversation, Francois mentioned that he feels like, you know, one to two months is the time frame we’re looking at for v2.
Speaker 2: Okay.
Speaker 4: In that conversation we were discussing how maybe we could do some specific guidelines for testing, so we can really bust this out and kind of test the last few pieces that need bedded.
Speaker 2: Yeah.
Speaker 4: One of the things we’re gonna be doing is, we’re going to be publishing some specific goals for public testing, so we can really hammer out some of these last things that need to be run through the ringer. And then, once those are done, I think we’re probably gonna be ready to release. Pretty soon.
Speaker 2: Okay.
Speaker 4: I’m not gonna say one to two months, but I think, definitely I think by the end of the year, we will have v2 in people’s hands.
Speaker 2: Based on yesterday’s discussions, the Q42 018 was reinforced as viable.
Speaker 4: Yeah. Oh yeah.
Speaker 2: Okay. Great. I guess, I would ask you something … For example …
Justin Renken: I guess I would ask you something like, for example, are there any major challenges left with v2 whose solutions are unknown, to get v2 out there? Or is it just simply testing to make sure the robustness is there?
Speaker 4: No, there’s no unknown solutions, or anything that hasn’t been coded, and that isn’t already essentially done. There are still some things we’re working on to refine the transaction pool processing. I don’t know if you saw, but we just hired another core developer, and he’s actually working on a lot of those pieces, taking a look at the transaction pool, and trying to refine some things.
Speaker 4: Hopefully, we can get that a little bit better processing. We had some instances on testnet, or on devnet, where people were trying to put through thousands of transactions at one time, and we were still losing a few of the transactions here and there, so one of the things we’re trying to do is just shore up that process and make sure that they’re getting in the queue properly, that they’re getting accepted, and getting out there. That will be one of the things that we keep testing and keep working on.
Speaker 4: Other than that, it’s really just vetting the dynamic fee system, and some of the other new, major changes that are in this version, that I think will make a big difference. A lot of people were still asking questions about how dynamic fees work, and trying to understand the process, so we have a new blog post that will be coming out in the next few days that will explain a couple of different ways, and try to whittle it down, so people can really understand what’s happening with the dynamic fees.
Speaker 4: I think it’s a really cool system. I think it adds a lot. I think people are really going to like it, so we’re just trying to make sure that everybody understands it, and that we get time to test that, as well.
Justin Renken: That sounds really handy. I think that a blog post about dynamic fees are really going to help. As I understand ARK is going to be the very first Delegated Proof of Stake system to implement dynamic fees. Is that correct?
Speaker 4: As far as I know, yeah. I don’t think anybody’s done it before.
Justin Renken: Yeah, nobody’s challenged that statement yet, so it’s probably true.
Speaker 4: Yeah. If nobody’s said they did it, then sure. Yeah. We’re the first.
Justin Renken: Okay. Let me ask you this. Regarding the dynamic fees, how are the dynamic fees going to be integrated into the wallets to make sure that the user experience is as easy as possible? Because I do know that one of the reasons why I, personally, as a community member really got into ARK and liked ARK is knowing that the fee is always going to be the same, I guess. Just from a convenience standpoint, not necessarily a “make sure the fee’s as low as possible,” but I don’t have to do math to know how much money I need to send the other party. How would the wallets be intuitive for the dynamic fees?
Speaker 4: Sure. Like we said before, when we were talking about UI design and how important that is to us, this is a complicated new system. But the majority of the complications for this system will fall on the delegates in determining what fees they’ll accept. For the average user, I think it’s going to be pretty intuitive.
Justin Renken: Okay.
Speaker 4: The user can just go with the default. That will use the average of fee paid over the last 30 days.
Justin Renken: Okay.
Speaker 4: If you don’t do anything, if you go in and you don’t make any changes, and you don’t try to lower or increase your fee, you’ll just use the average of the last 30 days. That will ensure that you’re transaction is going to get through, maybe not on the next block, but pretty quickly.
Speaker 4: You have the option, though, of then setting minimum or maximum fees. You can tell it that, “Hey, I’m not worried about getting it through right away, and I want to go with lowest fee possible,” and you can set your fee low, and eventually it will probably get through. Or you can set it to the cap, which is pretty much what the current fees are right now. The maximum the network is going to allow after v2 is what the hard cap is right now at 0.1 ARK for a transaction.
Justin Renken: Okay.
Speaker 4: You’ll never pay more than what you’re paying right now. Even if you max it out, and you say, “No I want to guarantee that my transaction is going to be on the next block,” you will pay the same as the current fee.
Justin Renken: Got it.
Speaker 4: But you can then also try to lower it, if you want to. But for most people, the average is probably going to be the best bet. You don’t need to change anything, and it’s just going to give you the average fee for the last 30 days, which is pretty reasonable, I think, and they won’t need to do anything to do that.
Justin Renken: Okay, well that sounds like it’s going to work out great.
Speaker 4: Yep. I think people, once they see it … We haven’t been able to get the new wallet version out that shows what the system is going to look like, yet, so I think once people see it and actually get their hands on it, they’ll realize that it’s pretty easy to use.
Justin Renken: Okay. Excellent. Well, I know that everything that ARK has released so far has been really above and beyond at least my expectations, in terms of ease-of-use, power, and accessibility, so I have no reason to randomly change my mind about that.
Speaker 4: Yeah, well, and here’s the thing, right? We have this process where we’re going to build it. We’re going to do the design that we have from Oleg, and that we think is intuitive. And if we put it out there and people start using it on devnet, and it’s not intuitive, and that they hate it, then we’ll adapt. We’ll change it, and we’ll talk to the community, and we’ll find out what the issues are, and then we’ll make it work.
Speaker 4: Our goal is always going to be to make it as easy as possible. If we put it out there, and people have ideas, ways to make it easier, or they just don’t like what we built, then we’ll go back and we’ll do it better.
Justin Renken: Let’s check out this content about ARKv2 in Episode 12.
Justin Renken: Altcoin Magazine continued, saying “Tell us about your accomplishment so far, and tell us what you are most proud of having accomplished in the history of the project?”
Justin Renken: Well, I said, “The simplest way to highlight all of ARK’s many accomplishments is to visit the community resource ArkTimeline.com, which is a vast, interactive experience tallying every ARK event since its inception in late 2016, and mainnet launch in early 2017. All ARK events are searchable, easily categorized, and filterable, giving anyone an immediate bird’s eye view of ARK’s ability to deliver. ArkTimeline.com was built and deployed by the ARK Community Committee, which I run.”
Justin Renken: Altcoin Magazine continued, saying, “What is the single coolest thing about your project? It can be something you developed, or something you achieved.”
Justin Renken: Well, I responded to that question by saying, “I would be remiss to try to answer this on my own, so I’ll start with something most community members would probably say, given the chance. The coolest thing about the ARK.io project is very likely the wallets. ARK has beautiful desktop, mobile, paper, and web wallets focused on ease of use for the general public. The wallets run instantly without needing to sync, and users receive voting rewards even when their wallets are offline. Voting rewards are similar to the staking rewards you hear about on some other projects, and they are a voluntary aspect of the ARK delegate system. ARK.io does not control the ARK network. Delegates give voting rewards voluntarily, and voting rewards are not part of the ARK protocol. I strongly recommend experiencing our wallets, as they are a big reason our community has grown so large.”
Justin Renken: Altcoin Magazine then said, “Give us a quick rundown of the future of the project. What are you seeking to bring to life, and what will it mean for the overall project?”
Justin Renken: I responded with, “In the short term, our goal is to complete the newly rewritten core codebase, dubbed ARK Core v2. This new Core, which will be at the heart of ARK and ARK-based chains, achieves monumental strides in reliability, power, versatility, and convenience. This is the next logical evolution of ARK’s grand vision and it will deal away with the old Lisk and Crypti code beneath the current ARK codebase. ARKv2 is a bottom-up redesign built by ARK with love … no forks, no derivation. ARKv2 sports unique solutions to complex blockchain architecture problems.”
Justin Renken: “Once ARKv2 is purring along on mainnet, our next major plan is to complete and implement powerful plugin modules that can interface directly with the new ARK Core. Namely, ARK Virtual Machine for smart contract execution, similar to Ethereum, and ARK IPFS, or Inter-Planetary File System, for decentralized large-format file storage. Concurrently, we will be completing and releasing a Core 2.1 release for new transaction types and protocol functionality, as well as complete our Push Button Blockchain Graphical User Interface, for intuitive customization and deployment of impressive blockchains. All ARK products have easy baked into nearly every aspect, and anyone can check ARK’s efforts and progress at ARK.io/Roadmap.”
Justin Renken: “ARK’s vision will be realized when anyone who needs blockchain technology can deploy their own custom implementation of the tech in a reliable and secure manner, all without much, or any, programming knowledge at all. These user-deployed chains are all optionally linkable, forming the larger ARK Ecosystem.”
Justin Renken: All right. That’s going to do it for this episode of the ARK Crypto Podcast. Tune in next week, when you’ll start hearing special small segments for other projects, here on the cast. You can subscribe on iTunes, Google Play, Soundcloud, Stitcher, Spotify, and Castbox. You can also follow us on Twitter @ ark_podcast, where you can stream directly inside of our tweets. How cool is that? We’ll see you next time.