You are reading content from Scuttlebutt
Feed of @cel

dedidexidev: dedicated decentralization developer

Mobile: @6RpN4Zt...
Desktop: @lOUVT+P...
Pub: @5XaVcAJ...

git-ssb · ssb-npm · patchfoo · sbotc

Please include the Desktop identity above if private-messaging me anything time-sensitive.

@cel
Voted ![borsok.png](&IVUmPH0iQUhqvtCg3xAai4B1vEO8CC2cPXBEjVoZjp0=.sha256) I just
@cel
Re: %DmI5fvTdu

recorded talk with a live Q&A element right after it.

Maybe also Q&A in chat during the presentation

@gwil

ethstar

Did you ask the organizers to change that?

@cel
Re: %w9BpmlFJR

The References and In-Reply-To headers are used for mail threading. The Subject might be used as a fallback. I haven't heard of using the message body for threading; that is interesting.

@cel
Did a git update
-Fix
@cel
Did a git update
-Fix
@cel
Did a git update
-Enable some usage with ssb-db2
-Remove trailing space in message names
@cel
Re: %ZqSf2KPzj

I don't know if I would use this functionality, because I don't really use rooms currently.
Given the end-to-principle of decentralization, I would think it would be preferable to move functionality to the end-nodes, peers, rather than to add functionality to rooms, for what I understand to be an authorization protocol. If it is a concern of DoS, perhaps a special provisional or restricted mode could be added for new connections from unknown peers, where RPC is limited until the user approves the connection/request or the connecting peer authenticates with their token (i.e. the doorknock idea in %j2EJzTS... ). Limiting resource usage use for a connected peer at the socket level should be possible by limiting the receive buffer, i.e. just not reading from the TCP socket. This may mean reworking the stream modules, since the ssbc/muxrpc implementation currently reads continuously and buffers unboundedly. The case where I could see a need for third parties to broker authorization claims would be for privacy: to accept a SHS connection, you must confirm/reveal your public key to the client as part of the handshake; while if you reject during the handshake, it looks the same as if the connection failed because of a wrong public key or network key. In the context of rooms, I'm not sure if this privacy possibility would be realized or useful, since the room might already be claiming that the peer is in the room, and/or the peer might already be publicly self-identified with the room.

@cel
Voted [@andrestaltz](@QlCTpvY7p9ty2yOFrv1WU1AE88aoQc4Y7wYal7PFc+w=.ed25519) I hav

Show whole feed
Join Scuttlebutt now