Ory Keto VS libpeer

One of Ory’s core competencies is permissions. We built the first Google Zanzibar implementation in the world and it’s part of Ory Network‘s global multi-region platform (https://github.com/ory/keto)

A push model is also valid if you’re heavy on policies and can accept eventual consistency. We will investigate how to generally push things to the edge (like we did with Ory Edge Sessions) or to cryptographic verification wherever staleness is acceptable.

By solving the primitives correctly in the beginning (with a multi region architecture) that job does become a lot easier, which is what we decided doing at Ory :)

slightly off-topic, but related to what ory is doing in general. How do you usually do authorization-aware search?

Imagine, I have a bunch of Google docs and using https://github.com/ory/keto for authorization. I can quickly answer the question "does user X have access to document Y", but it is not easy to do "search all documents with word Hello in it, for which I have access" because access can be granted through nested groups (give read access to everyone in DepartmentA, and I am part of child department)

if you want to integrate an existing framework see if https://github.com/ory/keto solves your problems, there are similiar frameworks that support ABAC

Shameless plug for Ory Keto, probably the best reference implementation IMO https://github.com/ory/keto

Looks cool, wonder how it compares to Keto and Casbin.

How does Warrant compare to other Zanzibar based solutions like Ory Keto ?https://github.com/ory/keto

Interesting to see another project open sourced around Google Zanzibar. On a timeline for context:

- Ory came out first with Ory Keto ( https://github.com/ory/keto ) which is trying to be a close adaptation of the paper. Initially, many concepts were missing but they are making a lot of progress with the DSL and it interfaces with the rest of Ory (OAuth2, User Mangement)

- Authzed came out as a SaaS only, open sorucing the code base later on at https://github.com/authzed/spicedb

- Auth0 has been playing around with Zanzibar concepts in various forms and published a beta service at https://dashboard.fga.dev - apparently now also open source parts of it similar to what Authzed did: https://github.com/openfga

- Permify - who on a side note spammed me quite a lot with outreach because I was active in these communities - joins as well https://github.com/Permify/permify

It's exciting to see so much movement, yet also sad that so many companies are brewing their own beer instead of working collaborative on the more succesful projects. Feels like we'll just end up with one or two successful projects (looking at Ory / Auth0 here) with the rest perishing. I'm wondering if there truly is a business model for just this permission system as a saas service (looks like this is what everyone is going with). Here I'm giving Auth0 probably the biggest plus as they have an established identity service. Then again, Okta (parent of Auth0) and Auth0 themselves are not particularly known for good business practices that we usually expect from developer tooling.

What's refreshing though with Permify is that they are trying a bit of a different approach to Zanzibar!

Er, Ory Keto is written in Go.

I am really excited about https://github.com/sepfy/libpeer. It has examples ready for ESP32 etc....

When working on KVS I wasn't familiar with the embedded space at all. I saw 'heavyweight' embedded where you were running on Linux. Then you had RTOS/No OS at all. I wasn't prepared for these devices at all. If we can make WebRTC work in the embedded space I think it will really accelerate what developers are able to build!

Remotely driven cars, security cameras, robots in hospitals that bring iPads to infectious patients etc... Creative people are building amazing things. The WebRTC/video space needs to work harder and support them :)

-----

I love how diverse the WebRTC space is now. Outside of this implementation you have plenty of other options!

* https://github.com/shinyoshiaki/werift-webrtc (Typescript)

* https://github.com/pion/webrtc (Golang)

* https://github.com/webrtc-rs/webrtc (Rust)

* https://github.com/algesten/str0m (Rust)

* hhttps://github.com/sepfy/libpeer (C/Embedded)

* https://webrtc.googlesource.com/src/ (C++)

* https://github.com/sipsorcery-org/sipsorcery (C#)

* https://github.com/paullouisageneau/libdatachannel (C++)

* https://github.com/elixir-webrtc (Elixir)

* https://github.com/aiortc/aiortc (Python)

* GStreamer’s webrtcbin (C)

See https://github.com/sipsorcery/webrtc-echoes for examples of some running against each other.

I am experimenting based on the pear project (https://github.com/sepfy/pear) and using the clumsy tool to simulate the case of dropping packets.

A simple C implementation to stream H.264 to browser using WebRTC\ (61 comments)

I think there's some truth in what as-j is saying. Rust binaries (and C++ ones) tend to be larger than C ones. I think the major reasons are (a) Rust dependencies being statically linked due to a lack of ABI stability, (b) inclusion of portions of the (statically linked, see a) Rust standard library used by the program where C code uses libc, (c) code bloat due to monomorphization, (d) the ease of just using a full-featured library where someone writing in C might cheat a little bit. As an example of what I mean by the last point, see sdp_attribute_get_answer in this codebase. [1] It's writing JSON, but it doesn't use a JSON library that actually escapes the included string. It just assumes the included string doesn't have a quote character in it. Is that assumption valid? Will it always be valid? I'm not sure on quick inspection.

There are ways around all of these:

* a. Static vs dynamic linkage: in an embedded system, it'd be reasonable to just produce a single userspace binary that does everything. It can change its behavior based on argv[0]. I think this is not too unusual for constrained systems even with C binaries. Eg busybox does it. If you only have one binary, you don't need dynamic linking. Also, I think it's not strictly true that Rust doesn't support dynamic linking. I think you can dynamically link everything if you ensure the whole system is built with the same compiler version.

* b. Standard library. You don't have to use it at all, or you can use it sparingly, paying only for what you use.

* c. Monomorphization. You could write (for example) a Go-like map [2] rather than relying so heavily on monomorphization. I'd love to see someone take this idea as far as possible; it might be a good idea for a lot of non-inner-loop code in general, not just on tight embedded systems.

* d. Using full-featured libraries. Obviously no one is making you do this; the same cheats available in C are available in Rust.

but in fairness, the further you go down this path, the further you are from just being able to just take advantage of the whole Rust ecosystem.

Personally, I'd still rather develop or use a #![no_std] Rust codebase than a C one. Memory safety is important to me. IOT devices are no exception to that. Their security is historically horrible but I'd like to change that.

[1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a...

[2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...