pings.metadata in users/timeline

[katanacrimson]

What purpose does this metadata entry serve? If it is to indicate permissions, why isn't it also provided through other endpoints such as users/pings?

[katanacrimson]

Looking through metadata information, this information really needs to be in all the endpoints if it's going to be useful. Otherwise, we've got to do it ourselves on all but a couple routes, and then we might as well disregard it entirely; plus, with issue #35, the metadata isn't that trustworthy.

[caseym]

Right now, Ping metadata is available when an API call is executed with authentication against an endpoint that returns Ping related information. It's purpose is to provide a vehicle for transmitting information about a Ping we feel could be useful to have.

Ping metadata will not always be available, as you can lookup information about Pings on various endpoints that don't require authentication. In those cases, the meta data isn't necessarily meaningful.

In cases where a user is authenticated, the additional meta data is available at the moment.

can_reply: Always true at the moment, but we reserve this space for future development

can_delete: If the authenticated user is the owner of the Ping, then the authenticated user can delete the Ping

can_echo: re issue: #35 , you can echo any Pings that the authenticated user is not the owner of the Ping. In cases of echo'ing an echo. The owner of an echo Ping is the owner of the original Ping, not the echo, that is why you can echo an already echoed Ping.

is_private: self explanatory

[katanacrimson]

Well, GET users/pings doesn't provide these can_* metadata entries, I'm digging through other endpoints as well. users/timeline and users/notifications do though.

For can_echo meaning we can echo an echo of our own ping, that really doesn't make sense; I don't think that's the best idea. Seems like that could cause undue flooding (two users echoing echos back and forth would be confusing as hell to see for the everyday user), and it also makes for the UI being a bit...odd (if you use it as visual cues to display an echo button or action).

[caseym]

Remember, GET users/pings does not require authentication, if you're calling it without an access token, it won't include any meta data. You can however, call any endpoint with an access token, and if we can use it we will treat it like an authenticated call.

[katanacrimson]

...Son of a - the developer site isn't sending an access token then and there's no option to, visibly, for that endpoint. No wonder I'm not seeing it. Thanks, I'll have to get a bit lower-level for sample data I guess.

Side-note, can checkboxes to use auth be added for unauthed routes on the dev sites? That might help reduce future confusion for others. ^^;

[caseym]

Yeah, since it's not required, it didn't get added, however, it would probably be useful to allow it since it can be useful even if not required.

[katanacrimson]

Yeah. My apologies for this bit of mess, was completely unaware that such was the behavior.

[caseym]

Also, to clarify, maybe I was unclear:

Say User A creates a new ping with ID = 1 User A cannot echo Ping of ID = 1 because they are the owner of that Ping.

Say User B creates a new ping with ID = 2 User A can echo Ping of ID = 2 because User B is the owner of that Ping User A can also echo their echo of Ping ID = 2, because User B is still considered the owner since it's an echo User B cannot echo Ping ID = 2, nor can they echo any of User A's echo's.

[katanacrimson]

Ah, but then -

• A creates ID 1
• B echoes id 1 to create id 2

Can A echo id 2 to create another, say id 3? Can B then echo id 3 to create id 4?

My point - recursive echoing/ownership. Since you're not a direct owner, you can continue echoing...that is what I'm concerned with and worried of.

[caseym]

A cannot echo id 2 in that case.

B can infinitely echo id 1 or their original echo id 2

[katanacrimson]

Alright; I'll probably hook this into my own application to restrict it visually to prevent confusion. If current user is owner of the echo or the echoed content, the cue will not appear to allow echoing.