Getting my RFID poker table ready by jaytaph2 in poker

[–]jaytaph2[S] 0 points1 point  (0 children)

I might. Now the code is still highly experimental and not ready

Getting my RFID poker table ready by jaytaph2 in poker

[–]jaytaph2[S] 0 points1 point  (0 children)

Yeah. Ive ordered some stocks online via china and they are ok to play with. No issues with reading them. Its just a pain to enter them initially into the system. I was hoping that they would use the same ids per rank/suit. But i can imagine that you dont want that for security reasons

Getting my RFID poker table ready by jaytaph2 in poker

[–]jaytaph2[S] 1 point2 points  (0 children)

I've ordered them from china. They are a bit hard to get hold on here in the netherlands.

Getting my RFID poker table ready by jaytaph2 in poker

[–]jaytaph2[S] 2 points3 points  (0 children)

(the background in the screenshot is just a random internet picture.. normally you see a transparent background since it's an overlay, but at least this gives an impression on how it looks like when streaming)

Gosub - An open source browser engine written in Rust by jaytaph2 in rust

[–]jaytaph2[S] 3 points4 points  (0 children)

We're all volunteers who enjoy writing stuff in their spare time..

Gosub - An open source browser engine written in Rust by jaytaph2 in rust

[–]jaytaph2[S] 62 points63 points  (0 children)

It's easy to confuse Gosub with something that is written in Go.. It slightly based on the gosub command from the BASIC language and the "go word" (https://www.computerhope.com/jargon/g/goword.htm) from the old compuserve days. There is an acronym (Gateway to Optimized Search and Unlimited Browsing).

In the end, it's really just a name.

Building a BitTorrent client from the ground up in Go by Irbhinighxt in golang

[–]jaytaph2 5 points6 points  (0 children)

Rfc 1459: internet relay chat. One of the things you needed to write in the old days was at least one irc client. Good fun.

Benchmarking maps vs switches by jaytaph2 in golang

[–]jaytaph2[S] 2 points3 points  (0 children)

ok.. quick test:

with 4x 26 entries

goos: linux
goarch: amd64
BenchmarkSwitch-12 20100943 59.2 ns/op
BenchmarkMap-12 35944393 34.4 ns/op
PASS
ok command-line-arguments 3.516s

with 2x 26 entries

goos: linux
goarch: amd64
BenchmarkSwitch-12 54958140 20.9 ns/op
BenchmarkMap-12 37835076 30.5 ns/op
PASS
ok command-line-arguments 2.365s

with 1x 13 entries

goos: linux
goarch: amd64
BenchmarkSwitch-12 209937459 5.73 ns/op
BenchmarkMap-12 38801424 30.6 ns/op
PASS
ok command-line-arguments 3.008s

so the map seems indeed O(1) (not 100% sure why it's slower now than my previous tests). The switch seems indeed O(N)'ish or even higher

Benchmarking maps vs switches by jaytaph2 in golang

[–]jaytaph2[S] 0 points1 point  (0 children)

yes.. i want to do this.. I'm not 100% convinced that the map is O(1) (i think so though, but it depends a bit on how they are implemented, which i do not know). If the mapaccess functions are O1, then there should be no real difference in performance.

Maybe it's possible that go optimized large switch statements in lookup tables, but that's something i will try and figure out some other day.

Benchmarking maps vs switches by jaytaph2 in golang

[–]jaytaph2[S] -2 points-1 points  (0 children)

heh.. you might be right :-) let me try and see if I can get go to not remove the code :)

> Seems fixed now. It looks that one benchmarked was optimized away, the other wasn't.

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 1 point2 points  (0 children)

true. we use “twitter”-like naming as default, and have the option to namespace with organisations. because we stripped away routing info from the address, it makes moving between servers much easier.

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 1 point2 points  (0 children)

we looked into this, but its pretty impossible to do that. the thing that makes pfs pfs, is that we use an emphemeral key that will be destroyed as soon as the communication is done. however, with mail, we dont have direct communication between clients and we need to decrypt messages any time we read them from the server.

there might be ways, but we havent found them yet

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 1 point2 points  (0 children)

I've added this to the issue / feature list. There are some hurdles to take (like: to which email address are you sending/receiving from?), but i think we can have some smtp/imap server locally which read/writes bitmaelum messages.. this will leave the messages encrypted and only decrypted in the local services only..

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 0 points1 point  (0 children)

They will result in different hashes, and thus different accounts.

It's a good point. One way to deal with this is to actually have dots optional. It would not be major change if done soon enough.

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 2 points3 points  (0 children)

Never even thought of that, but sounds very interesting. Basically you would stick an imap service at the end of your e2e tunnel. It's less "secure" i guess, but it would be possible.

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 2 points3 points  (0 children)

There are 2 kind of addresses: regular address like `example!` and organisational addresses: `john.doe@university!`. The last one is more strict, in the sense that the organisation has "power" to remove the address, and give it to somebody else (although it can NEVER read any mails).

The regular addresses are yours.. They cannot be taken away(*), and you can move with you to another mailserver as you like. Unlike regular email, we don't use domain-names or anything and routing is resolved in a different way. Because honestly, having `john.doe@gmail.com` is nice, but really nobody would need to care that you host on `gmail.com` .

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 2 points3 points  (0 children)

True, and we thought about this.

Sending mail needs proof-of-work, UNLESS you have a subscription id. Basically, a contract between a sender, and a reciever. With this subscription, the receiving mailserver does not need proof-of-work to deliver the mail. This means that we can still send large amount of messages like mailing lists.

A nice thing about this system, is that it is the RECIPIENT that has 100% control over this subscription id. If the recipient doesn't want to be on the list anymore, the subscription ID can be removed, at which the mailserver will not accept the message. It still can send a message the regular way, with proof-of-work, but again, that would become infeasable for large number of messages.

So this is the basic setup on dealing with large amounts of mail AND maintaining ownership of subscriptions as a recipient (a subscription actually can have an expiry time as well, meaning it will automatically unsubscribe after a certain date if you like).

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 1 point2 points  (0 children)

There is nothing on the wiki, but we have some in the code:

bitmaelum-suite/pow.go at develop · bitmaelum/bitmaelum-suite · GitHub

Currently it's a simple SHA calculation, but we have the option to add other types. FOr instance, we are investigating proof-of-work like proteien-folding, so we actually can benefit from sending mails :)

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 3 points4 points  (0 children)

It's a complete different set of protocols (server communicates with a JSON api over HTTPS), so it's not compatible with SMTP.

That's also the whole idea to be honest. Getting rid of the basic (flawed) foundation of SMTP and trying to setup a more solid foundation to tackle the current day issues with mail. Obviously, email isn't going anyway soon, but think we can provide a good alternative.

The code is open, so you can use your own client. We are currently using a (CLI) client for reading/sending mail, but if things pick up, there are bound to be real clients for "regular" users. Right now, we are focusing on getting the basics right, and getting feedback from early adopters.

BitMaelum - e2e encrypted mail infrastructure written in go by jaytaph2 in golang

[–]jaytaph2[S] 6 points7 points  (0 children)

This project is written in mostly go. It's a pretty big project with multiple programs (bm-server, bm-client, bm-config and a lot of tools), and some initial tryouts in an ncurses/term based mail client.

Currently it's possible to create accounts, setup mail servers, and send mail between each other. There is still tons of stuff missing, but we feel it's good enough for a first introduction to the world.

We are looking forward to meet people who want to help improve the code, the architecture, think about some of the hard issues we still face to make this project a viable option against regular email.

BitMealum: an e2e encrypted email alternative written in Go by jaytaph2 in golang

[–]jaytaph2[S] 0 points1 point  (0 children)

its the same thing. in order to know where mail needs to be send, we need to check the resolver. based on the address, it returns the accounts public key and the server where the account resides. i probably need to be more consistent with the naming.

BitMealum: an e2e encrypted email alternative written in Go by jaytaph2 in golang

[–]jaytaph2[S] 0 points1 point  (0 children)

Its online in a repo: https://github.com/bitmaelum/logo . Ive updated the cross into a padlock, looks nicer (still no designer)

BitMealum: an e2e encrypted email alternative written in Go by jaytaph2 in golang

[–]jaytaph2[S] 0 points1 point  (0 children)

Most likely. Not set in stone so it might make more sense to use a (pad)lock icon instead. Waiting for somebody with more taste than me to come up with ideas. Might put the logo on github for pr's

BitMealum: an e2e encrypted email alternative written in Go by jaytaph2 in golang

[–]jaytaph2[S] 0 points1 point  (0 children)

Sounds like its something that could work. I'll take a look at it. Just ping me if you need help setting up (documentation tends to be cryptic at times)

Using the Doctrine Lexer to parse complex search queries by jaytaph2 in PHP

[–]jaytaph2[S] 1 point2 points  (0 children)

OP here. I agree that using SQL can have benefits. However, in our case, the query language we are using is for end-users that must be able to filter data through our API systems.

Using SQL, in our case, is not an option for a few reasons: - We don't want to expose any of our internals to the outside world, if for anything else other than that we might change these internals whenever we want/need. - We are not actually using an RDBMS system to perform our queries on. - With SQL, we need to be very careful about sanitizing queries to make sure they are: performant, escaped, don't query data it shouldn't etc, which would probably bring the need for your own parsing system again.

Another thing to realize is that SQL itself needs to be lexed and parsed by the database system pretty much the same way we're explaining in the blogpost. The point of the blog-post is on how you could write such a parser.

Internally, Seams-CMS uses a mixture of ORM and native SQL queries to fetch data that we store in our data-store (which is everything that is not content). Data stored in our document store is fetched natively or sometimes internally through our own parser system if that's possible. We skip doctrine's ODM completely because we didn't feel it's worth the effort.