Post 3076408 by kaniini@pleroma.site
(DIR) More posts by kaniini@pleroma.site
(DIR) Post #3076359 by kaniini@pleroma.site
2019-01-17T19:44:44.568978Z
3 likes, 0 repeats
don't @ me mode is pretty easy by the way: it turns out that what we can combine a capability URI with forwarding a Create object that references a remote object ID, and this should work mostly everywhere. need to test how robust Mastodon is though :)
(DIR) Post #3076408 by kaniini@pleroma.site
2019-01-17T19:46:01.833933Z
0 likes, 0 repeats
to enforce OCAP, we just do not send messages which require it (due to enhanced security context) to servers which don't support OCAP. my proposal for that is to use whether or not OCAP capabilities are present on remote actors from an instance to determine whether or not OCAP is present.
(DIR) Post #3076462 by kaniini@pleroma.site
2019-01-17T19:48:07.055236Z
0 likes, 0 repeats
blog about this illustrating some examples tonight, probably. all of this is built on fundamentals proven by the SL Open Grid Protocol. need to verify a few minor details, but prototyping has been quite promising so far.i don't need to wait until february to provide solutions, they can be provided today.
(DIR) Post #3076910 by LaH@mastodon.host
2019-01-17T20:03:58Z
0 likes, 0 repeats
@kaniini But what problem do it solve?instances can still just silently not delete stuff.clients can just silently not delete stuff.users can still take screen shots and save to disk.I can only see it provide a more convincing and even more dangerous illusion. At a cost on top of that.
(DIR) Post #3076911 by kaniini@pleroma.site
2019-01-17T20:05:26.880647Z
0 likes, 0 repeats
@LaH this isn't about deletion, but about correcting security fundamentals.oh, and it has never been about *deletion*, it's about *deniability*. i have written about that, too.
(DIR) Post #3077182 by LaH@mastodon.host
2019-01-17T20:14:53Z
0 likes, 0 repeats
@kaniini I read it and deniability is a slightly more valid concern. But those keeping copies will be crooks, cops, spooks and journalists. Don't think deniability will work. Courts still accept screen shot of IP addresses as proof from copyright trolls with tons of documented abuse. The fact that message can be spoofed by compromised instances probably add more deniability.
(DIR) Post #3077183 by kaniini@pleroma.site
2019-01-17T20:16:56.054694Z
2 likes, 0 repeats
@LaH well, this is one of the worst excuses for halfassing security i have seen yet. good job.
(DIR) Post #3077378 by LaH@mastodon.host
2019-01-17T20:21:48Z
0 likes, 0 repeats
@kaniini Pleroma seams to do some relaying. But in general, don't toot go from user a -> instance A -> instance B -> user b. Won't we in any case have to trust instance A and B.Sans real end to end security in the clients. But then deniability is harder.
(DIR) Post #3077379 by kaniini@pleroma.site
2019-01-17T20:24:56.918622Z
1 likes, 0 repeats
@LaH newsflash: end users have to make trust decisions about the places where they store their data, film at 11(one of the main reasons why Pleroma is intended to be easy as possible to set up and as low cost as possible to deploy, is to enable everyone to be their own node in the fediverse.)
(DIR) Post #3078421 by LaH@mastodon.host
2019-01-17T21:01:47Z
0 likes, 0 repeats
@kaniini Users running there own instances is the main reason I dislike capability URIs. Now You need a IP with incoming access, a domain name and certificate to run an AP instance. That exclude most users. VPS add one more actor to trust.My plan is users running an AP instance *on there own* computer. Login on a proxie server with client credentials but talking server to server AP. The proxy server only queue incoming messages and cache the latest outgoing objects. Everything else is only available when the users AP server are connected. Witch may be sporadic and connections in the other direction might be impossible. If already delivered messages get deleted because the users instance is offline it would be annoying. If we have to *ask* for that functionality (witch I think You hinted at somewhere) it OK I guess.
(DIR) Post #3078422 by kaniini@pleroma.site
2019-01-17T21:05:16.696911Z
0 likes, 0 repeats
@LaH there is nothing that requires capability URIs to be http(s). they could be dat URIs for example, if you can convince implementations to actually implement dat.but Pleroma is about building fediverse tech today, at scale.
(DIR) Post #3078839 by LaH@mastodon.host
2019-01-17T21:17:18Z
0 likes, 0 repeats
@kaniini Do I get it right if the proxy don't have a capability url for 'proxie users' they work but might not get all messages?Some might be able to have them if the proxy can connect to them and they are up all the time. But some wont.But assuming user run instances to have high accessibility is a bit optimistic under all circumstances.
(DIR) Post #3078840 by kaniini@pleroma.site
2019-01-17T21:19:33.799088Z
0 likes, 0 repeats
@LaH unlike Mastodon, Pleroma does a good job at recovering from those conditions.
(DIR) Post #3079200 by LaH@mastodon.host
2019-01-17T21:33:22Z
0 likes, 0 repeats
@kaniini When are capability URIs to be used? If it to check whether You can reply to or boost a toot it's no big issue.But if it's used every time a user view a message, already delivered messages will disappear when an there instance is down - that is annoying as hell. And then they might need to be re-fetched taking that instance down again... etc.
(DIR) Post #3079201 by kaniini@pleroma.site
2019-01-17T21:34:05.344110Z
0 likes, 0 repeats
@LaH it's only used in federated transactions. once a message is delivered to you, they have nothing to do with anything.
(DIR) Post #3079419 by LaH@mastodon.host
2019-01-17T21:40:42Z
0 likes, 0 repeats
@kaniini Is federated transactions basically "relayed delivery"?
(DIR) Post #3079420 by kaniini@pleroma.site
2019-01-17T21:41:12.503584Z
0 likes, 0 repeats
@LaH yes, sure
(DIR) Post #3079520 by LaH@mastodon.host
2019-01-17T21:44:26Z
0 likes, 0 repeats
@kaniini So if a user don't have a capability URI it basically mean that messages need to be delivered/fetched from the originating instance directly?Seams OK actually. And can probably coexist with alternative forms of relaying.
(DIR) Post #3079521 by kaniini@pleroma.site
2019-01-17T21:45:11.348659Z
0 likes, 0 repeats
@LaH yes, something like that. please wait until i explain more in the blog.
(DIR) Post #3079583 by dirb@social.beepboop.ga
2019-01-17T21:47:19.411628Z
0 likes, 0 repeats
@kaniini but this will work with public posts?
(DIR) Post #3079614 by kaniini@pleroma.site
2019-01-17T21:48:19.334632Z
1 likes, 0 repeats
@dirb yes, for private posts a way of authenticating access would be needed, but we can use HTTPSigs for that (with server actors)
(DIR) Post #3080415 by dirb@social.beepboop.ga
2019-01-17T22:13:16.996875Z
0 likes, 0 repeats
@kaniini wouldn't it affect other interactions, like favorites and repeats? and what if they get it through the public url?
(DIR) Post #3080469 by kaniini@pleroma.site
2019-01-17T22:15:42.849453Z
1 likes, 0 repeats
@dirb for liking a post, it wouldn’t.for announces (repeats, boosts, whatever), basically posts which are OCAP-labelled would use cap URLs in the protocol as object instead of the real id.implementations could then make access decisions when presented with requests for the object at the real id (such as not returning it except via the cap URL)