odinho

(Tana eng) That's not good!

Someone is looking into it now.

You can go through the back-door currently here: https://app.tana.inc/create-account (currently requires credit card to get in directly, but you can cancel it directly after).

I used to work on the Opera browser. I quit when it got sold to China. Also wanted to do that, since most people as well as main Oslo HQ was fired from Poland a year earlier.

Opera was very much a not-dubious company. But that is what it has turned in to.

-- I use Firefox as my main work-browser, and have for a long time, and the last few years I've used Vivaldi as my main personal browser.

I find it easier to just have separate browsers rather than do anything more advanced for context. :)

What Ansible resources do you use for Nomad, Consul and Vault though? I've found a few but they all seem to lag behind release. Noone is up to date at Nomad 1.0.3. Would be nice with some half-way standard way of setting it up, like k8s has quite a few projects that do.

Why? That is the thing that excites me the most. Though it isn't thightly locked with the whole STX-side of things which isn't as interesting to me.

Only needing some "dumb" storage media to store your application data and "cloud" files unlocks suddenly a user-centric way for everyone to store data. It also unlocks real competition on the infrastructure layer.

You don't make your own generator and make your own power, -- you don't buy power from say Dell because it needs "Dell electricity". Data should be like this too, ability to be owned and controlled purely by the user (as in you have solar panels + battery) or what most people would do: delegate the work to a power provider.

Ofc not real competition in the "power provider" case since there's physical stuff happening, but for data storage (and batch/"offline" computation and event/webhook handling) a user will be able to set up their own raspberry pi or just use say Amazon to store the encrypted data. :)

I find it fits 100% in to the world I'd want to live in. ^_^

Thanks! It is very valuable with feedback like this, even if in this case we're painfully aware of it. :)

I was working on fixing up that when COVID-19 hit. Now we're trying to stamp out more obscure audio+video bugs (like bluetooth, which can be unreliable). We're in process of hiring a few more people so we can hopefully put someone on caring more for the non-logged in mobile app experience.

You do get a join button once you've logged in. But I must confess it is not a good experience by default. It used to be on the top of the priority list, but then scaling and any video/audio issues jumped to the top.

Hehe, I see. Yeah copy and marketing is hard. I think we should try to re-do that one. It's hard to get right for all cases.

A p2p room can have 4 total people in it. So say you plus 3 concurrent guests, none of those guests need any account or "user".

Indeed even you don't have to log in after you've created the room if you leave it unlocked. :)

Actually, if you are using 4+ rooms, we will in many cases be better than some other webrtc services because we for these bigger rooms use a server in the middle to distribute all the streams. That will result in lower resource use. You only encode and send once, and it is distributed by the server. But if other webrtc kills CPU on 4 or less, we probably won't be much better.

This "more than 4 room" is not p2p and end-to-end encrypted, since the server (SFU) needs to read and change some headers. So it is a tradeoff. There's now "insertable streams" which allow you to do encryption on the media client side, but it's a test for now: https://webrtchacks.com/true-end-to-end-encryption-with-webr...

We have used a lot of time making it work on Safari. And we continue to use quite substantial resources on it. Their webrtc implementation is quite new, and not as stable as Chrome and Firefox. And with new code comes new bugs.

There is currently a bug with audio, where it'll crash in Safari, -- and we have had some issues reconnects that was more our fault (though Firefox and Chrome is much more forgiving). We have a workaround for the first, and will be doing a fix for the second once we're reasonably sure it won't regress other browsers.

Is it any of those issues you talk about? Or is it something else? (I'm not personally familiar with the Safari issues, btw, since I'm a Linux user, but I keep an eye on Firefox and Chromium-based browsers)

A Whereby-developer here. It's awesome you recommend us. <3 But we'll also kill your CPU ^_^

You can turn on "mobile mode" in advanced device settings, and it should be a bit better. But we're a bit limited in how CPU-friendly we really can be, living in the browser. Not that we can't improve, there's certainly extra tricks we could try - but not easily without also lowering fps and resolution.

I don't think "low resource use" is a big selling-argument for our product. Video can be quite heavy.

Hi, one Whereby-developer here. I use Vivaldi and Firefox on Linux mostly. So you could rather say we over-test Chromium-based browsers on Linux. Also test in "real" Chrome and open up Opera now and then, and Brave quite infrequently.

But the API we get from the browser is basically just `navigator.mediaDevices.getDisplayMedia()`, so what we do to screenshare is actually not much code at all. If we do something bad for Vivaldi/Brave though, we'll be quick to fix it, but this is likely their bugs, not ours :) Vivaldi screensharing on Linux broke half a year or so ago, but we're in the same town and know them, so they quickly fixed whatever bug it must have been after we pinged them.

But the most likely thing here is just that they might not have updated to newest Chromium with all these fixes. Or maybe not done the necessary platform-integrations or UI for it. Having worked on Opera previously I know anything involving chrome (UI) will often take a lot longer to do because you actually have to write a lot of custom code for it (in contrast to pure web-platform features and improvements, which basically will be free).

Thanks! This is excellent.

I was actually notified of this article in the Google news screen on my phone, but forgot the name after reading the article.

How are they storing this? I understand the links, there is enough bits to do that, but an image stored on-chain? How?

Over several transactions and you need to put it together, or will there be enough space to store an image in a OP_RETURN script?

83 bytes doesn't sound like it's enough to store any abuse image.

Blockstack 'Gaia' is a bit like that. But more focused on the actual storage services like Google Drive / S3 / Dropbox. Mentioned in the whitepaper: https://blockstack.org/papers

Blockstack can use IPFS for storage. If you create "mycoolapp.app" (or "myname.id" to use a namespace that currently exists), you can store application code or even data in IPFS (using the http-gateway just like you did now).

Blockstack provides naming, identity and security (you know what public key is connected to "myname.id").

I do not know of Solid. But IPFS is a storage layer, so you can use IPFS as part of Blockstack. It is even normally mentioned in the architecture diagrams. Have a look at the picture down on the page here: https://blockstack.org/intro

Where it says "storage layer" it has things like Dropbox and S3, in some versions of the picture it also has IPFS. This is up to the user. As long as you can fetch it, it can be used. Usually that would mean you'd have to use HTTP, but it depends on the browser you're running.

You can also read about 'Gaia' (where it uses storage as Dropbox/S3 as 'dumb harddrives' where it can dump encrypted blobs on) in the whitepaper: https://blockstack.org/whitepaper.pdf

Blockstack project originally ran on namecoin. But it is not a secure blockchain.

Also, it stores much data in the blockchain, so it has scaling problems. Blockstack stores the zone file data in its own Atlas (DHT-inspired) network, and the zone files point to where the actual application-level data is stored.

Blockstack can work on top of any blockchain, so if Bitcoin is not the most secure anymore, it could be moved. Separating into different layers allows scaling and resiliency. And you don't have to run a blockchain, which is good, because that already exists.

You're burning that money. Noone gets it. If it costs 0.025 btc you're trying to register a very short name. Try a longer one, it's a lot cheaper.

I've registered an ID. I did it through onename.com which pays the registration fee for you (as a way to get more people into it, it won't stay that way).

Read the blockstack papers, they're the best info around and makes everything clearer. It is a bit hard to wrap heads around. I've been trying to unsuccessfully explain it many times, there's so many good ideas and so much potential there!

(I'm unaffiliated btw, but have been following the project for a long time)

No. The data record hash is only about your zone file. The zone file is just like DNS. It can point to different things. So say you point 'profile' to 'mywebsite.com/myprofile.json', and then in your profile you can update things about yourself independently. Just make sure to always attach a signature to it, so people can verify that you actually did that.

Here's a profile: https://blockstack.s3.amazonaws.com/muneeb.id

Here's how a simple zone file looks (from https://onename.com/muneeb.json):

  $ORIGIN muneeb.id
  $TTL 3600
  _http._tcp IN URI 10 1 "https://blockstack.s3.amazonaws.com/muneeb.id"

No, you don't need the whole internet.

You can't run application code with just pure HTML. The processing code has to run somewhere. Blockstack runs it using Javascript in your browser, and with bring your own storage.

Only naming (identity) is pegged to Bitcoin, blockstack has a virtual blockchain on top of this which has functionality akin to DNS (and CA). That DNS can point to your storage, so you can have things on Dropbox or Amazon S3 or wherever.

So it scales pretty well, you don't download what you're not interested it. It will work with a lot of infrastructre/services that exist, but you can cut out a lot of middle men.

You could host your application code on your Amazon S3. But when a user runs it, the app can store private data in THEIR chosen storage. And if you have public data, that could be either stored with their chosen storage without encryption (only signature) so it is public, or indeed you could store it in your application storage.

This is so wrong I don't even know what to say.

Python is a beautiful object oriented language. Very much so.

Java is not different at all, I'd say go for Haskell or similar to get something really truly dif

Oh, can you point to something here? Some vision document, brainstorming, back-of-napkin spec? Anything?

I would not be surprised to find out that many open source communities would love to switch to a better list software than Mailman. It would need to work well for the main list use case of course - so that switching would cost nothing and people could connect to the waves in their own time.

They started pump.io instead. Which is a much more low-level project than StatusNet. Trying to build a federation-server that other people can make services on top of.

Trying to win a market that way. If only one popular site starts to use it, -- you might be getting some network effect out of it.

I think it was a better level to work on. Let others help with the network.

Yes it should :-) I had to do quite a bit of research to find out who maintains that page and could update it. But found them in the end and that papercut is reported. I'll check it again tomorrow to see if it has been fixed :-)

Mailing lists are not the same as labels. Labels and Mailing lists are two different features (albeit very similar).

Mailing list only looks at the List-Id: email header. Facebook is sending that in its emails, and that's why it gets its own "Mailing list" automatic entry.

Not that beautiful, I agree.

Ouch! Looking at it. Have created a bug about it already, so no need to report.

Yes, we have a shipped XML configuration file which finds and sets up many common domains automatically.

Supports IMAP and POP. Mail providers like gmail, yahoo and hotmail should work pretty well. Doesn't do calendaring. Runs on WinXP. Don't know about that old OS X version, but I think it probably does. Runs on old Linux (when we release the Linux version that is). You don't even need gtk or qt, though it'll use them if it can find them.

I work on Linux version of Opera Mail. Windows and Mac is released today. A rc/test version of Linux will follow soon.

(What is soon, you ask. Well that depends, but I guess in this case over a month would /not/ be soon.)

Usage. Installed/downloaded is very high.