secondlife / jira-archive

2 stars 0 forks source link

[BUG-234236] Group webhooks #11198

Open sl-service-account opened 11 months ago

sl-service-account commented 11 months ago

How would you like the feature to work?

Creation and Permissions:

Groups can create webhooks, each with permissions such as "Create notice", "Send message", "Invite residents", "Kick residents", "Getting member list", etc Creation of webhooks is restricted behind a "Create webhooks" permission + The power the resident has(EG: A resident with webhook permissions but no kick resident permissions cannot create a webhook with kick residents capabilities).

When executing a webhook, it is executed as the group it's self. So for example, sending a message sends it in group chat as "Group name: ".

Example capabilities:

Endpoint can probably be the same global caps URL: https://cap.secondlife.com/cap/0/UUID/ACTION

By default, the following return:


{
    "success": bool success,
    "reason": string reason,
    "data": mixed data
}

Reason is optional, only present if success is false. Data is optional, only present if there is data.

Sending messages:

POST /messages


{
    "message": string messageBody
}

Sending a message results in this being sent to chat: [[HOUR]:[MINUTE]] secondlife:///app/group/[GROUP_ID]/inspect: [MESSAGE]

Creating notices:

POST /notices


{
    "type": int type,
    "subject": string subject,
    "message": string message
}

type is 0 for notice (Default), 1 for poll (Old deprecated polls, if they ever are brought back might be useful to have this ready)

Inviting residents:

POST /members


{
    "UUID": {
        "payPrice": integer cost,
        "roles": [string role, ...]
    }
}

payPrice is default to the groups join fee. roles is default to ["everyone"]

Kicking residents:

DELETE /members


{
    "UUID": {
        "reason": string reason,
        "ban": bool yesKick
    }
}

if ban is true, ban them as well

Edit residents:

UPDATE /members


{
    "UUID": {
        "roles": [string role, ...]
    }
}

Update resident roles in group

Getting members:

GET /members?role[]=rolename&role[]=rolename2&agent[]=key if role[] is undefined, default to ["everyone"], unless agent[] is defined. if agent is defined, return info for hose agents, in addition to previous roles if requested. Returns data:


{
    "UUID": {
        "roles": [string role, ...],
        "permissions": integer permissionMask,
        "title": string title,
        "status": string status
    }
}

There can be more, maybe not even limited to groups.

Mitigating abuse

Residents who abuse webhooks(Mass invites, etc), can have their webhook permissions revoked account wide. (Any existing webhooks are deleted, creation of webhooks denied by server) Groups who abuse webhooks can also have their webhook permissions revoked for the entire group. (Any existing webhooks are deleted, creation of webhooks denied by server) If the creator of the webhook is kicked or leaves the group, the webhooks are removed.

It might be ideal to have a "Audit log" in the group that shows the history of the group. This could be used for various purposes other than just webhooks, such as:

  1. Logging on a specific or all webhooks
  2. Show kick/ban history
  3. Show invite history
  4. Group insignia and description changes
  5. Role changes

Why is this feature important to you? How would it benefit the community?

Currently we must rely on bots for doing a lot of stuff, this can be tedious, have reliability issues, and so forth. Discord currently provides webhooks to do various stuff in group chats. I think this would be a great addition to allow invite people to their group or send shared notifications to moderators in a moderator group, without having to rely on automated services.

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-234236 | | Summary | Group webhooks | | Type | New Feature Request | | Priority | Unset | | Status | Needs More Info | | Resolution | Unresolved | | Reporter | Chaser Zaks (chaser.zaks) | | Created at | 2023-08-09T20:32:04Z | | Updated at | 2023-08-16T18:21:04Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-08-10T01:47:29.344-0500', 'How would you like the feature to work?': 'filling in', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'why must the create issue window be so tiny', } ```
sl-service-account commented 11 months ago

Peter Stindberg commented at 2023-08-10T06:47:29Z

A very good idea! This would remove the need for an estimated 95% of bots around, which clog ressources, consume energy for basically nothing, and are generally a cumbersome thing to use for lack of an alternative.

sl-service-account commented 11 months ago

Kadah Coba commented at 2023-08-11T02:12:30Z

+1 for a websocket, or similar, for 2-way group chat support. Being able to sync in-world group chat to a community's Discord, or another platform, would really help these community's increase activity and decrease discontinuity.

Bonus points if it can be generic and universal enough to allow for an offline SL IM client.

sl-service-account commented 11 months ago

Spidey Linden commented at 2023-08-16T18:21:04Z

Thanks for the suggestion! Could you tell us a little bit more about the issues you've seen with bots for this use?