saranixseeing those actual example jsons really helps. I started writing up a followup example that adds to the issue... have to take a food break though
jaywinkWhy do you need to rebuild signatures for remote objects? Local objects you can always sign whenever, remote objects can be verified at the source. I think this is thought of a bit too complex.
jaywinkYou could store the original signature as is for remote objects, but then you must be sure to provide the object as it was received. Which probably would not always be possible.
tanteksaranix: we've discussed the use and (non)-requirement of tools at W3C in the past, and I wanted to bring back some work on that for your review and further input. Here's an ongoing wiki page listing various tools in use at W3C in various degrees: https://www.w3.org/wiki/AB/Tooling
tantekall: since I think all CG members should have accounts to W3C wiki, please feel free to add other tools that the CG is explicitly using to get its work done. or you may also tell me and I can do the edits. either way no problem.
xmpp-social[ajordan] tantek: in theory everyone has access but I believe a number of people have run into problems similar to the ones I had a couple months ago
tantekDoes anyone have summary documentation of the "follow" vs. "reject" (and even "block") interactions that were mentioned here in chat the past few days week?
xmpp-social[ajordan] tantek: yeah it's unclear as to whether it's a problem with ACLs or just the wiki not handling "interesting" passwords. I've suggested a couple things to them, including asking in #sysreq if the rest doesn't work, but I don't know if they ever followed up
saranixmore importantly, it's not a big deal for the UI to show that an accept/reject was never received. it's a UX issue and should definitely not be normative in the spec
cwebber2saranix: it seems that this problem is more general than just Accept/Reject though; you could DDOS AP servers generally with many kinds of activities (or even most servers with any kind of requests)
Loqi[strugee] It seems to me that when we do this we should also mention that servers should ratelimit C2S interactions, because if they "blindly" pass through data then a malicious user could get their server on another server's blacklist for DoS problems.
xmpp-social[ajordan] In this case the "deputy" is the malicious user's server and it's a problem because said user can get the "deputy" blacklisted on other instances
cwebber2Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like Like
xmpp-social[ajordan] You need C2S rate limiting to a) avoid being overloaded yourself and b) to avoid overloading others so much that you trigger their S2S DoS protection
ben_thatmustbemeif you rate limit s2s sending, you are going to have really bad UI, sorry, i can't send your friend request now, as i am talking to (other popular server) too much right now
saranixjust throwing this out there: one way to do UX this is like cloud providers do with email-- you can only send x/hr as a new user unless you explain usecase to admin
ben_thatmustbemearguably someone could just create thousands upon thousands of accounts on on system and then use multiple accounts to do the same, but thats also sort of outside of the spec of the scope
jaywinksaranix: "the most desirable advantage of ldsig is the embed capability, so that sigs can be verified without fetch" <--- I would say the most desirable feature is verifying content :) But anyway, the point was, to bring something difficult into the spec, we might have to stop at some point. Simple is better than complex. I just feel the whole signatures discussion is taken on a way too complex path. Or
saranixjaywink: "the most desirable feature is verifying content" <-- yes but ld-sigs allows embedding foreign objects, that's the advantage over say http-sigs
saranixI'm doing work on both fronts-- writing up the issues involved, and also a possible breakage scenario that I thought up, but I have to work through the json to see if it's true
jaywinkbtw, someone asked about facebook follow vs friend. Follow means "I follow your public content", Friend means "I requested friendship, you accept/deny". Follow doesn't even cause a notification AFAICR.
tantekthat's what I remember, and it makes sense because it's a gentler gesture, and provides the followee the opportunity to "follow back" should they wish to do so, or perhaps even "upgrade" by responding with a friend request
tantekindeed. would be nice if we had a better understanding of what/which follow vs friend models / implied protocols were out there now so we have an idea of what they have in common vs differences
tanteknevermind what "should" be standardized which is entirely a different question, but hard to do a good job answering without first researching and documenting existing examples to see what user models are expected to be modeled by the plumbing underneath
jaywinkfacebook follow is basically the same as twitter follow. Diaspora has something that is a monster child in between. When you add a person to an aspect, you 1) follow the person and 2) share your limited content in that aspect. I think though they're planning on separating them, AFAICR.
tantekjaywink: while I agree with the commonality of the public content use-case, there are many "limited audience" use-cases that people seem to use FB for
tantekmy understanding was d* aspects were an attempt to provide a viable alternative to FB limited audience posts in order to help encourage / make it easier for folks to use d* instead
jaywinktantek: yes d* came out 2010. And sure, I'm not saying limited audience use cases are not important. Just my personal preference is public use case :) Especially on Facebook, I'm quite sure (from following friends) that a large part or even a clear majority of posts are limited.
cwebber2that's a distinction I think getting caught up in this: "I want to subscribe to someone's public posts" vs "I want to subscribe to someone's public posts and their limited-audience posts"
tantekcwebber2: I dunno either (from a which UX is more desirable perspective), hence I'm trying to document (and ask for help documenting) the various existing models which have clearly been through some user-feedback/iteration and thus are worth seriously considering supporting with any protocol
jaywinkfor Socialhome I'm anyway going to implement contact lists which can be used for targeting private posts. Similar to aspects, but without the requirement of following the person you want to post to. In this case, in AP, it wouldn't be the followers list at all, but just a list of people. I think it makes more sense because sometimes you might want to post only to for example colleagues, sometimes friends,
jaywinkit could be we're trying to lock some of the verbs and meanings in AS/AP too much into UX. the reality is, implemneters will be free to do their own interactions and business logic in their apps.
tantekjaywink - agreed trying to minimize locking some of the meanings. however I think we have to explicitly design for flexibility at the protocol level to enable the various UX variants
jaywinkcwebber2: I don't see a need for accept/Reject on a follow at all for my use cases, but I understand if someone does. Though currently I'm unsure how this would be different from a Friend request in AP. A friend request (in FB for example) is a special symmetrical relationship that grants special rights for both parties when accepted. A follow, even if accepted, to me just makes the other person follow
jaywinkwishes he had time to hack some limited AP support into Socialhome to actually be able to contribute to these kind of discussions in more than just theory :P
saranixtantek: not if you replace a standard that works for some uses cases that is then left out after you make changes because you missed it in your research
saranix seeing those actual example jsons really helps. I started writing up a followup example that adds to the issue... have to take a food break though
@angusscown @michaelneale Hopefully better when the work to pull in the w3c standards is finished https://www.w3.org/TR/social-web-protocols/ (twitter.com/_/status/887958420187369474)
ben_thatmustbeme looks at conversation backlog, blinks, and walks away
tantek saranix: we've discussed the use and (non)-requirement of tools at W3C in the past, and I wanted to bring back some work on that for your review and further input. Here's an ongoing wiki page listing various tools in use at W3C in various degrees: https://www.w3.org/wiki/AB/Tooling
jaywink saranix: "the most desirable advantage of ldsig is the embed capability, so that sigs can be verified without fetch" <--- I would say the most desirable feature is verifying content :) But anyway, the point was, to bring something difficult into the spec, we might have to stop at some point. Simple is better than complex. I just feel the whole signatures discussion is taken on a way too complex path. Or