Merge pull request #2988 from wbamberg/support-rendered-data
Support rendered data
This commit is contained in:
wbamberg
Richard van der Hoff
commit
e88a18ca5d
391 changed files with 2827 additions and 12330 deletions
|
|
@ -5,9 +5,10 @@ gendoc: &gendoc
|
|||
scripts/gendoc.py
|
||||
|
||||
genswagger: &genswagger
|
||||
name: Generate the swagger
|
||||
name: Validate sources and generate swagger json
|
||||
command: |
|
||||
source /env/bin/activate
|
||||
scripts/check-swagger-sources.py
|
||||
scripts/dump-swagger.py
|
||||
|
||||
buildswaggerui: &buildswaggerui
|
||||
|
|
@ -27,10 +28,7 @@ checkexamples: &checkexamples
|
|||
name: Check Event Examples
|
||||
command: |
|
||||
source /env/bin/activate
|
||||
cd event-schemas
|
||||
./check_examples.py
|
||||
cd ../api
|
||||
./check_examples.py
|
||||
scripts/check-event-schema-examples.py
|
||||
|
||||
genmatrixassets: &genmatrixassets
|
||||
name: Generate/Verify matrix.org assets
|
||||
|
|
@ -41,9 +39,9 @@ genmatrixassets: &genmatrixassets
|
|||
validateapi: &validateapi
|
||||
name: Validate OpenAPI specifications
|
||||
command: |
|
||||
cd api
|
||||
cd scripts
|
||||
npm install
|
||||
node validator.js -s "client-server"
|
||||
node validator.js -s "../data/api/client-server"
|
||||
|
||||
buildspeculator: &buildspeculator
|
||||
name: Build Speculator
|
||||
|
|
|
|||
|
|
@ -1,2 +0,0 @@
|
|||
This directory contains swagger-compatible representations of our APIs. See
|
||||
the main README.rst for details on how to make use of them.
|
||||
|
|
@ -1 +0,0 @@
|
|||
../../../event-schemas
|
||||
38
api/files/backbone-min.js
vendored
38
api/files/backbone-min.js
vendored
|
|
@ -1,38 +0,0 @@
|
|||
// Backbone.js 0.9.2
|
||||
|
||||
// (c) 2010-2012 Jeremy Ashkenas, DocumentCloud Inc.
|
||||
// Backbone may be freely distributed under the MIT license.
|
||||
// For all details and documentation:
|
||||
// http://backbonejs.org
|
||||
(function(){var l=this,y=l.Backbone,z=Array.prototype.slice,A=Array.prototype.splice,g;g="undefined"!==typeof exports?exports:l.Backbone={};g.VERSION="0.9.2";var f=l._;!f&&"undefined"!==typeof require&&(f=require("underscore"));var i=l.jQuery||l.Zepto||l.ender;g.setDomLibrary=function(a){i=a};g.noConflict=function(){l.Backbone=y;return this};g.emulateHTTP=!1;g.emulateJSON=!1;var p=/\s+/,k=g.Events={on:function(a,b,c){var d,e,f,g,j;if(!b)return this;a=a.split(p);for(d=this._callbacks||(this._callbacks=
|
||||
{});e=a.shift();)f=(j=d[e])?j.tail:{},f.next=g={},f.context=c,f.callback=b,d[e]={tail:g,next:j?j.next:f};return this},off:function(a,b,c){var d,e,h,g,j,q;if(e=this._callbacks){if(!a&&!b&&!c)return delete this._callbacks,this;for(a=a?a.split(p):f.keys(e);d=a.shift();)if(h=e[d],delete e[d],h&&(b||c))for(g=h.tail;(h=h.next)!==g;)if(j=h.callback,q=h.context,b&&j!==b||c&&q!==c)this.on(d,j,q);return this}},trigger:function(a){var b,c,d,e,f,g;if(!(d=this._callbacks))return this;f=d.all;a=a.split(p);for(g=
|
||||
z.call(arguments,1);b=a.shift();){if(c=d[b])for(e=c.tail;(c=c.next)!==e;)c.callback.apply(c.context||this,g);if(c=f){e=c.tail;for(b=[b].concat(g);(c=c.next)!==e;)c.callback.apply(c.context||this,b)}}return this}};k.bind=k.on;k.unbind=k.off;var o=g.Model=function(a,b){var c;a||(a={});b&&b.parse&&(a=this.parse(a));if(c=n(this,"defaults"))a=f.extend({},c,a);b&&b.collection&&(this.collection=b.collection);this.attributes={};this._escapedAttributes={};this.cid=f.uniqueId("c");this.changed={};this._silent=
|
||||
{};this._pending={};this.set(a,{silent:!0});this.changed={};this._silent={};this._pending={};this._previousAttributes=f.clone(this.attributes);this.initialize.apply(this,arguments)};f.extend(o.prototype,k,{changed:null,_silent:null,_pending:null,idAttribute:"id",initialize:function(){},toJSON:function(){return f.clone(this.attributes)},get:function(a){return this.attributes[a]},escape:function(a){var b;if(b=this._escapedAttributes[a])return b;b=this.get(a);return this._escapedAttributes[a]=f.escape(null==
|
||||
b?"":""+b)},has:function(a){return null!=this.get(a)},set:function(a,b,c){var d,e;f.isObject(a)||null==a?(d=a,c=b):(d={},d[a]=b);c||(c={});if(!d)return this;d instanceof o&&(d=d.attributes);if(c.unset)for(e in d)d[e]=void 0;if(!this._validate(d,c))return!1;this.idAttribute in d&&(this.id=d[this.idAttribute]);var b=c.changes={},h=this.attributes,g=this._escapedAttributes,j=this._previousAttributes||{};for(e in d){a=d[e];if(!f.isEqual(h[e],a)||c.unset&&f.has(h,e))delete g[e],(c.silent?this._silent:
|
||||
b)[e]=!0;c.unset?delete h[e]:h[e]=a;!f.isEqual(j[e],a)||f.has(h,e)!=f.has(j,e)?(this.changed[e]=a,c.silent||(this._pending[e]=!0)):(delete this.changed[e],delete this._pending[e])}c.silent||this.change(c);return this},unset:function(a,b){(b||(b={})).unset=!0;return this.set(a,null,b)},clear:function(a){(a||(a={})).unset=!0;return this.set(f.clone(this.attributes),a)},fetch:function(a){var a=a?f.clone(a):{},b=this,c=a.success;a.success=function(d,e,f){if(!b.set(b.parse(d,f),a))return!1;c&&c(b,d)};
|
||||
a.error=g.wrapError(a.error,b,a);return(this.sync||g.sync).call(this,"read",this,a)},save:function(a,b,c){var d,e;f.isObject(a)||null==a?(d=a,c=b):(d={},d[a]=b);c=c?f.clone(c):{};if(c.wait){if(!this._validate(d,c))return!1;e=f.clone(this.attributes)}a=f.extend({},c,{silent:!0});if(d&&!this.set(d,c.wait?a:c))return!1;var h=this,i=c.success;c.success=function(a,b,e){b=h.parse(a,e);if(c.wait){delete c.wait;b=f.extend(d||{},b)}if(!h.set(b,c))return false;i?i(h,a):h.trigger("sync",h,a,c)};c.error=g.wrapError(c.error,
|
||||
h,c);b=this.isNew()?"create":"update";b=(this.sync||g.sync).call(this,b,this,c);c.wait&&this.set(e,a);return b},destroy:function(a){var a=a?f.clone(a):{},b=this,c=a.success,d=function(){b.trigger("destroy",b,b.collection,a)};if(this.isNew())return d(),!1;a.success=function(e){a.wait&&d();c?c(b,e):b.trigger("sync",b,e,a)};a.error=g.wrapError(a.error,b,a);var e=(this.sync||g.sync).call(this,"delete",this,a);a.wait||d();return e},url:function(){var a=n(this,"urlRoot")||n(this.collection,"url")||t();
|
||||
return this.isNew()?a:a+("/"==a.charAt(a.length-1)?"":"/")+encodeURIComponent(this.id)},parse:function(a){return a},clone:function(){return new this.constructor(this.attributes)},isNew:function(){return null==this.id},change:function(a){a||(a={});var b=this._changing;this._changing=!0;for(var c in this._silent)this._pending[c]=!0;var d=f.extend({},a.changes,this._silent);this._silent={};for(c in d)this.trigger("change:"+c,this,this.get(c),a);if(b)return this;for(;!f.isEmpty(this._pending);){this._pending=
|
||||
{};this.trigger("change",this,a);for(c in this.changed)!this._pending[c]&&!this._silent[c]&&delete this.changed[c];this._previousAttributes=f.clone(this.attributes)}this._changing=!1;return this},hasChanged:function(a){return!arguments.length?!f.isEmpty(this.changed):f.has(this.changed,a)},changedAttributes:function(a){if(!a)return this.hasChanged()?f.clone(this.changed):!1;var b,c=!1,d=this._previousAttributes,e;for(e in a)if(!f.isEqual(d[e],b=a[e]))(c||(c={}))[e]=b;return c},previous:function(a){return!arguments.length||
|
||||
!this._previousAttributes?null:this._previousAttributes[a]},previousAttributes:function(){return f.clone(this._previousAttributes)},isValid:function(){return!this.validate(this.attributes)},_validate:function(a,b){if(b.silent||!this.validate)return!0;var a=f.extend({},this.attributes,a),c=this.validate(a,b);if(!c)return!0;b&&b.error?b.error(this,c,b):this.trigger("error",this,c,b);return!1}});var r=g.Collection=function(a,b){b||(b={});b.model&&(this.model=b.model);b.comparator&&(this.comparator=b.comparator);
|
||||
this._reset();this.initialize.apply(this,arguments);a&&this.reset(a,{silent:!0,parse:b.parse})};f.extend(r.prototype,k,{model:o,initialize:function(){},toJSON:function(a){return this.map(function(b){return b.toJSON(a)})},add:function(a,b){var c,d,e,g,i,j={},k={},l=[];b||(b={});a=f.isArray(a)?a.slice():[a];c=0;for(d=a.length;c<d;c++){if(!(e=a[c]=this._prepareModel(a[c],b)))throw Error("Can't add an invalid model to a collection");g=e.cid;i=e.id;j[g]||this._byCid[g]||null!=i&&(k[i]||this._byId[i])?
|
||||
l.push(c):j[g]=k[i]=e}for(c=l.length;c--;)a.splice(l[c],1);c=0;for(d=a.length;c<d;c++)(e=a[c]).on("all",this._onModelEvent,this),this._byCid[e.cid]=e,null!=e.id&&(this._byId[e.id]=e);this.length+=d;A.apply(this.models,[null!=b.at?b.at:this.models.length,0].concat(a));this.comparator&&this.sort({silent:!0});if(b.silent)return this;c=0;for(d=this.models.length;c<d;c++)if(j[(e=this.models[c]).cid])b.index=c,e.trigger("add",e,this,b);return this},remove:function(a,b){var c,d,e,g;b||(b={});a=f.isArray(a)?
|
||||
a.slice():[a];c=0;for(d=a.length;c<d;c++)if(g=this.getByCid(a[c])||this.get(a[c]))delete this._byId[g.id],delete this._byCid[g.cid],e=this.indexOf(g),this.models.splice(e,1),this.length--,b.silent||(b.index=e,g.trigger("remove",g,this,b)),this._removeReference(g);return this},push:function(a,b){a=this._prepareModel(a,b);this.add(a,b);return a},pop:function(a){var b=this.at(this.length-1);this.remove(b,a);return b},unshift:function(a,b){a=this._prepareModel(a,b);this.add(a,f.extend({at:0},b));return a},
|
||||
shift:function(a){var b=this.at(0);this.remove(b,a);return b},get:function(a){return null==a?void 0:this._byId[null!=a.id?a.id:a]},getByCid:function(a){return a&&this._byCid[a.cid||a]},at:function(a){return this.models[a]},where:function(a){return f.isEmpty(a)?[]:this.filter(function(b){for(var c in a)if(a[c]!==b.get(c))return!1;return!0})},sort:function(a){a||(a={});if(!this.comparator)throw Error("Cannot sort a set without a comparator");var b=f.bind(this.comparator,this);1==this.comparator.length?
|
||||
this.models=this.sortBy(b):this.models.sort(b);a.silent||this.trigger("reset",this,a);return this},pluck:function(a){return f.map(this.models,function(b){return b.get(a)})},reset:function(a,b){a||(a=[]);b||(b={});for(var c=0,d=this.models.length;c<d;c++)this._removeReference(this.models[c]);this._reset();this.add(a,f.extend({silent:!0},b));b.silent||this.trigger("reset",this,b);return this},fetch:function(a){a=a?f.clone(a):{};void 0===a.parse&&(a.parse=!0);var b=this,c=a.success;a.success=function(d,
|
||||
e,f){b[a.add?"add":"reset"](b.parse(d,f),a);c&&c(b,d)};a.error=g.wrapError(a.error,b,a);return(this.sync||g.sync).call(this,"read",this,a)},create:function(a,b){var c=this,b=b?f.clone(b):{},a=this._prepareModel(a,b);if(!a)return!1;b.wait||c.add(a,b);var d=b.success;b.success=function(e,f){b.wait&&c.add(e,b);d?d(e,f):e.trigger("sync",a,f,b)};a.save(null,b);return a},parse:function(a){return a},chain:function(){return f(this.models).chain()},_reset:function(){this.length=0;this.models=[];this._byId=
|
||||
{};this._byCid={}},_prepareModel:function(a,b){b||(b={});a instanceof o?a.collection||(a.collection=this):(b.collection=this,a=new this.model(a,b),a._validate(a.attributes,b)||(a=!1));return a},_removeReference:function(a){this==a.collection&&delete a.collection;a.off("all",this._onModelEvent,this)},_onModelEvent:function(a,b,c,d){("add"==a||"remove"==a)&&c!=this||("destroy"==a&&this.remove(b,d),b&&a==="change:"+b.idAttribute&&(delete this._byId[b.previous(b.idAttribute)],this._byId[b.id]=b),this.trigger.apply(this,
|
||||
arguments))}});f.each("forEach,each,map,reduce,reduceRight,find,detect,filter,select,reject,every,all,some,any,include,contains,invoke,max,min,sortBy,sortedIndex,toArray,size,first,initial,rest,last,without,indexOf,shuffle,lastIndexOf,isEmpty,groupBy".split(","),function(a){r.prototype[a]=function(){return f[a].apply(f,[this.models].concat(f.toArray(arguments)))}});var u=g.Router=function(a){a||(a={});a.routes&&(this.routes=a.routes);this._bindRoutes();this.initialize.apply(this,arguments)},B=/:\w+/g,
|
||||
C=/\*\w+/g,D=/[-[\]{}()+?.,\\^$|#\s]/g;f.extend(u.prototype,k,{initialize:function(){},route:function(a,b,c){g.history||(g.history=new m);f.isRegExp(a)||(a=this._routeToRegExp(a));c||(c=this[b]);g.history.route(a,f.bind(function(d){d=this._extractParameters(a,d);c&&c.apply(this,d);this.trigger.apply(this,["route:"+b].concat(d));g.history.trigger("route",this,b,d)},this));return this},navigate:function(a,b){g.history.navigate(a,b)},_bindRoutes:function(){if(this.routes){var a=[],b;for(b in this.routes)a.unshift([b,
|
||||
this.routes[b]]);b=0;for(var c=a.length;b<c;b++)this.route(a[b][0],a[b][1],this[a[b][1]])}},_routeToRegExp:function(a){a=a.replace(D,"\\$&").replace(B,"([^/]+)").replace(C,"(.*?)");return RegExp("^"+a+"$")},_extractParameters:function(a,b){return a.exec(b).slice(1)}});var m=g.History=function(){this.handlers=[];f.bindAll(this,"checkUrl")},s=/^[#\/]/,E=/msie [\w.]+/;m.started=!1;f.extend(m.prototype,k,{interval:50,getHash:function(a){return(a=(a?a.location:window.location).href.match(/#(.*)$/))?a[1]:
|
||||
""},getFragment:function(a,b){if(null==a)if(this._hasPushState||b){var a=window.location.pathname,c=window.location.search;c&&(a+=c)}else a=this.getHash();a.indexOf(this.options.root)||(a=a.substr(this.options.root.length));return a.replace(s,"")},start:function(a){if(m.started)throw Error("Backbone.history has already been started");m.started=!0;this.options=f.extend({},{root:"/"},this.options,a);this._wantsHashChange=!1!==this.options.hashChange;this._wantsPushState=!!this.options.pushState;this._hasPushState=
|
||||
!(!this.options.pushState||!window.history||!window.history.pushState);var a=this.getFragment(),b=document.documentMode;if(b=E.exec(navigator.userAgent.toLowerCase())&&(!b||7>=b))this.iframe=i('<iframe src="javascript:0" tabindex="-1" />').hide().appendTo("body")[0].contentWindow,this.navigate(a);this._hasPushState?i(window).bind("popstate",this.checkUrl):this._wantsHashChange&&"onhashchange"in window&&!b?i(window).bind("hashchange",this.checkUrl):this._wantsHashChange&&(this._checkUrlInterval=setInterval(this.checkUrl,
|
||||
this.interval));this.fragment=a;a=window.location;b=a.pathname==this.options.root;if(this._wantsHashChange&&this._wantsPushState&&!this._hasPushState&&!b)return this.fragment=this.getFragment(null,!0),window.location.replace(this.options.root+"#"+this.fragment),!0;this._wantsPushState&&this._hasPushState&&b&&a.hash&&(this.fragment=this.getHash().replace(s,""),window.history.replaceState({},document.title,a.protocol+"//"+a.host+this.options.root+this.fragment));if(!this.options.silent)return this.loadUrl()},
|
||||
stop:function(){i(window).unbind("popstate",this.checkUrl).unbind("hashchange",this.checkUrl);clearInterval(this._checkUrlInterval);m.started=!1},route:function(a,b){this.handlers.unshift({route:a,callback:b})},checkUrl:function(){var a=this.getFragment();a==this.fragment&&this.iframe&&(a=this.getFragment(this.getHash(this.iframe)));if(a==this.fragment)return!1;this.iframe&&this.navigate(a);this.loadUrl()||this.loadUrl(this.getHash())},loadUrl:function(a){var b=this.fragment=this.getFragment(a);return f.any(this.handlers,
|
||||
function(a){if(a.route.test(b))return a.callback(b),!0})},navigate:function(a,b){if(!m.started)return!1;if(!b||!0===b)b={trigger:b};var c=(a||"").replace(s,"");this.fragment!=c&&(this._hasPushState?(0!=c.indexOf(this.options.root)&&(c=this.options.root+c),this.fragment=c,window.history[b.replace?"replaceState":"pushState"]({},document.title,c)):this._wantsHashChange?(this.fragment=c,this._updateHash(window.location,c,b.replace),this.iframe&&c!=this.getFragment(this.getHash(this.iframe))&&(b.replace||
|
||||
this.iframe.document.open().close(),this._updateHash(this.iframe.location,c,b.replace))):window.location.assign(this.options.root+a),b.trigger&&this.loadUrl(a))},_updateHash:function(a,b,c){c?a.replace(a.toString().replace(/(javascript:|#).*$/,"")+"#"+b):a.hash=b}});var v=g.View=function(a){this.cid=f.uniqueId("view");this._configure(a||{});this._ensureElement();this.initialize.apply(this,arguments);this.delegateEvents()},F=/^(\S+)\s*(.*)$/,w="model,collection,el,id,attributes,className,tagName".split(",");
|
||||
f.extend(v.prototype,k,{tagName:"div",$:function(a){return this.$el.find(a)},initialize:function(){},render:function(){return this},remove:function(){this.$el.remove();return this},make:function(a,b,c){a=document.createElement(a);b&&i(a).attr(b);c&&i(a).html(c);return a},setElement:function(a,b){this.$el&&this.undelegateEvents();this.$el=a instanceof i?a:i(a);this.el=this.$el[0];!1!==b&&this.delegateEvents();return this},delegateEvents:function(a){if(a||(a=n(this,"events"))){this.undelegateEvents();
|
||||
for(var b in a){var c=a[b];f.isFunction(c)||(c=this[a[b]]);if(!c)throw Error('Method "'+a[b]+'" does not exist');var d=b.match(F),e=d[1],d=d[2],c=f.bind(c,this),e=e+(".delegateEvents"+this.cid);""===d?this.$el.bind(e,c):this.$el.delegate(d,e,c)}}},undelegateEvents:function(){this.$el.unbind(".delegateEvents"+this.cid)},_configure:function(a){this.options&&(a=f.extend({},this.options,a));for(var b=0,c=w.length;b<c;b++){var d=w[b];a[d]&&(this[d]=a[d])}this.options=a},_ensureElement:function(){if(this.el)this.setElement(this.el,
|
||||
!1);else{var a=n(this,"attributes")||{};this.id&&(a.id=this.id);this.className&&(a["class"]=this.className);this.setElement(this.make(this.tagName,a),!1)}}});o.extend=r.extend=u.extend=v.extend=function(a,b){var c=G(this,a,b);c.extend=this.extend;return c};var H={create:"POST",update:"PUT","delete":"DELETE",read:"GET"};g.sync=function(a,b,c){var d=H[a];c||(c={});var e={type:d,dataType:"json"};c.url||(e.url=n(b,"url")||t());if(!c.data&&b&&("create"==a||"update"==a))e.contentType="application/json",
|
||||
e.data=JSON.stringify(b.toJSON());g.emulateJSON&&(e.contentType="application/x-www-form-urlencoded",e.data=e.data?{model:e.data}:{});if(g.emulateHTTP&&("PUT"===d||"DELETE"===d))g.emulateJSON&&(e.data._method=d),e.type="POST",e.beforeSend=function(a){a.setRequestHeader("X-HTTP-Method-Override",d)};"GET"!==e.type&&!g.emulateJSON&&(e.processData=!1);return i.ajax(f.extend(e,c))};g.wrapError=function(a,b,c){return function(d,e){e=d===b?e:d;a?a(b,e,c):b.trigger("error",b,e,c)}};var x=function(){},G=function(a,
|
||||
b,c){var d;d=b&&b.hasOwnProperty("constructor")?b.constructor:function(){a.apply(this,arguments)};f.extend(d,a);x.prototype=a.prototype;d.prototype=new x;b&&f.extend(d.prototype,b);c&&f.extend(d,c);d.prototype.constructor=d;d.__super__=a.prototype;return d},n=function(a,b){return!a||!a[b]?null:f.isFunction(a[b])?a[b]():a[b]},t=function(){throw Error('A "url" property or function must be specified');}}).call(this);
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
/* latin */
|
||||
@font-face {
|
||||
font-family: 'Droid Sans';
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Droid Sans'), local('DroidSans'), url(http://fonts.gstatic.com/s/droidsans/v5/s-BiyweUPV0v-yRb-cjciPk_vArhqVIZ0nv9q090hN8.woff2), format('woff2');
|
||||
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000;
|
||||
}
|
||||
/* latin */
|
||||
@font-face {
|
||||
font-family: 'Droid Sans';
|
||||
font-style: normal;
|
||||
font-weight: 700;
|
||||
src: local('Droid Sans Bold'), local('DroidSans-Bold'), url(http://fonts.gstatic.com/s/droidsans/v5/EFpQQyG9GqCrobXxL-KRMYWiMMZ7xLd792ULpGE4W_Y.woff2), format('woff2');
|
||||
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215, U+E0FF, U+EFFD, U+F000;
|
||||
}
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because one or more lines are too long
2
api/files/jquery-1.8.0.min.js
vendored
2
api/files/jquery-1.8.0.min.js
vendored
File diff suppressed because one or more lines are too long
18
api/files/jquery.ba-bbq.min.js
vendored
18
api/files/jquery.ba-bbq.min.js
vendored
|
|
@ -1,18 +0,0 @@
|
|||
/*
|
||||
* jQuery BBQ: Back Button & Query Library - v1.2.1 - 2/17/2010
|
||||
* http://benalman.com/projects/jquery-bbq-plugin/
|
||||
*
|
||||
* Copyright (c) 2010 "Cowboy" Ben Alman
|
||||
* Dual licensed under the MIT and GPL licenses.
|
||||
* http://benalman.com/about/license/
|
||||
*/
|
||||
(function($,p){var i,m=Array.prototype.slice,r=decodeURIComponent,a=$.param,c,l,v,b=$.bbq=$.bbq||{},q,u,j,e=$.event.special,d="hashchange",A="querystring",D="fragment",y="elemUrlAttr",g="location",k="href",t="src",x=/^.*\?|#.*$/g,w=/^.*\#/,h,C={};function E(F){return typeof F==="string"}function B(G){var F=m.call(arguments,1);return function(){return G.apply(this,F.concat(m.call(arguments)))}}function n(F){return F.replace(/^[^#]*#?(.*)$/,"$1")}function o(F){return F.replace(/(?:^[^?#]*\?([^#]*).*$)?.*/,"$1")}function f(H,M,F,I,G){var O,L,K,N,J;if(I!==i){K=F.match(H?/^([^#]*)\#?(.*)$/:/^([^#?]*)\??([^#]*)(#?.*)/);J=K[3]||"";if(G===2&&E(I)){L=I.replace(H?w:x,"")}else{N=l(K[2]);I=E(I)?l[H?D:A](I):I;L=G===2?I:G===1?$.extend({},I,N):$.extend({},N,I);L=a(L);if(H){L=L.replace(h,r)}}O=K[1]+(H?"#":L||!K[1]?"?":"")+L+J}else{O=M(F!==i?F:p[g][k])}return O}a[A]=B(f,0,o);a[D]=c=B(f,1,n);c.noEscape=function(G){G=G||"";var F=$.map(G.split(""),encodeURIComponent);h=new RegExp(F.join("|"),"g")};c.noEscape(",/");$.deparam=l=function(I,F){var H={},G={"true":!0,"false":!1,"null":null};$.each(I.replace(/\+/g," ").split("&"),function(L,Q){var K=Q.split("="),P=r(K[0]),J,O=H,M=0,R=P.split("]["),N=R.length-1;if(/\[/.test(R[0])&&/\]$/.test(R[N])){R[N]=R[N].replace(/\]$/,"");R=R.shift().split("[").concat(R);N=R.length-1}else{N=0}if(K.length===2){J=r(K[1]);if(F){J=J&&!isNaN(J)?+J:J==="undefined"?i:G[J]!==i?G[J]:J}if(N){for(;M<=N;M++){P=R[M]===""?O.length:R[M];O=O[P]=M<N?O[P]||(R[M+1]&&isNaN(R[M+1])?{}:[]):J}}else{if($.isArray(H[P])){H[P].push(J)}else{if(H[P]!==i){H[P]=[H[P],J]}else{H[P]=J}}}}else{if(P){H[P]=F?i:""}}});return H};function z(H,F,G){if(F===i||typeof F==="boolean"){G=F;F=a[H?D:A]()}else{F=E(F)?F.replace(H?w:x,""):F}return l(F,G)}l[A]=B(z,0);l[D]=v=B(z,1);$[y]||($[y]=function(F){return $.extend(C,F)})({a:k,base:k,iframe:t,img:t,input:t,form:"action",link:k,script:t});j=$[y];function s(I,G,H,F){if(!E(H)&&typeof H!=="object"){F=H;H=G;G=i}return this.each(function(){var L=$(this),J=G||j()[(this.nodeName||"").toLowerCase()]||"",K=J&&L.attr(J)||"";L.attr(J,a[I](K,H,F))})}$.fn[A]=B(s,A);$.fn[D]=B(s,D);b.pushState=q=function(I,F){if(E(I)&&/^#/.test(I)&&F===i){F=2}var H=I!==i,G=c(p[g][k],H?I:{},H?F:2);p[g][k]=G+(/#/.test(G)?"":"#")};b.getState=u=function(F,G){return F===i||typeof F==="boolean"?v(F):v(G)[F]};b.removeState=function(F){var G={};if(F!==i){G=u();$.each($.isArray(F)?F:arguments,function(I,H){delete G[H]})}q(G,2)};e[d]=$.extend(e[d],{add:function(F){var H;function G(J){var I=J[D]=c();J.getState=function(K,L){return K===i||typeof K==="boolean"?l(I,K):l(I,L)[K]};H.apply(this,arguments)}if($.isFunction(F)){H=F;return G}else{H=F.handler;F.handler=G}}})})(jQuery,this);
|
||||
/*
|
||||
* jQuery hashchange event - v1.2 - 2/11/2010
|
||||
* http://benalman.com/projects/jquery-hashchange-plugin/
|
||||
*
|
||||
* Copyright (c) 2010 "Cowboy" Ben Alman
|
||||
* Dual licensed under the MIT and GPL licenses.
|
||||
* http://benalman.com/about/license/
|
||||
*/
|
||||
(function($,i,b){var j,k=$.event.special,c="location",d="hashchange",l="href",f=$.browser,g=document.documentMode,h=f.msie&&(g===b||g<8),e="on"+d in i&&!h;function a(m){m=m||i[c][l];return m.replace(/^[^#]*#?(.*)$/,"$1")}$[d+"Delay"]=100;k[d]=$.extend(k[d],{setup:function(){if(e){return false}$(j.start)},teardown:function(){if(e){return false}$(j.stop)}});j=(function(){var m={},r,n,o,q;function p(){o=q=function(s){return s};if(h){n=$('<iframe src="javascript:0"/>').hide().insertAfter("body")[0].contentWindow;q=function(){return a(n.document[c][l])};o=function(u,s){if(u!==s){var t=n.document;t.open().close();t[c].hash="#"+u}};o(a())}}m.start=function(){if(r){return}var t=a();o||p();(function s(){var v=a(),u=q(t);if(v!==t){o(t=v,u);$(i).trigger(d)}else{if(u!==t){i[c][l]=i[c][l].replace(/#.*/,"")+"#"+u}}r=setTimeout(s,$[d+"Delay"])})()};m.stop=function(){if(!n){r&&clearTimeout(r);r=0}};return m})()})(jQuery,this);
|
||||
1
api/files/jquery.slideto.min.js
vendored
1
api/files/jquery.slideto.min.js
vendored
|
|
@ -1 +0,0 @@
|
|||
(function(b){b.fn.slideto=function(a){a=b.extend({slide_duration:"slow",highlight_duration:3E3,highlight:true,highlight_color:"#FFFF99"},a);return this.each(function(){obj=b(this);b("body").animate({scrollTop:obj.offset().top},a.slide_duration,function(){a.highlight&&b.ui.version&&obj.effect("highlight",{color:a.highlight_color},a.highlight_duration)})})}})(jQuery);
|
||||
8
api/files/jquery.wiggle.min.js
vendored
8
api/files/jquery.wiggle.min.js
vendored
|
|
@ -1,8 +0,0 @@
|
|||
/*
|
||||
jQuery Wiggle
|
||||
Author: WonderGroup, Jordan Thomas
|
||||
URL: http://labs.wondergroup.com/demos/mini-ui/index.html
|
||||
License: MIT (http://en.wikipedia.org/wiki/MIT_License)
|
||||
*/
|
||||
jQuery.fn.wiggle=function(o){var d={speed:50,wiggles:3,travel:5,callback:null};var o=jQuery.extend(d,o);return this.each(function(){var cache=this;var wrap=jQuery(this).wrap('<div class="wiggle-wrap"></div>').css("position","relative");var calls=0;for(i=1;i<=o.wiggles;i++){jQuery(this).animate({left:"-="+o.travel},o.speed).animate({left:"+="+o.travel*2},o.speed*2).animate({left:"-="+o.travel},o.speed,function(){calls++;if(jQuery(cache).parent().hasClass('wiggle-wrap')){jQuery(cache).parent().replaceWith(cache);}
|
||||
if(calls==o.wiggles&&jQuery.isFunction(o.callback)){o.callback();}});}});};
|
||||
|
|
@ -1,125 +0,0 @@
|
|||
/* http://meyerweb.com/eric/tools/css/reset/ v2.0 | 20110126 */
|
||||
html,
|
||||
body,
|
||||
div,
|
||||
span,
|
||||
applet,
|
||||
object,
|
||||
iframe,
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
p,
|
||||
blockquote,
|
||||
pre,
|
||||
a,
|
||||
abbr,
|
||||
acronym,
|
||||
address,
|
||||
big,
|
||||
cite,
|
||||
code,
|
||||
del,
|
||||
dfn,
|
||||
em,
|
||||
img,
|
||||
ins,
|
||||
kbd,
|
||||
q,
|
||||
s,
|
||||
samp,
|
||||
small,
|
||||
strike,
|
||||
strong,
|
||||
sub,
|
||||
sup,
|
||||
tt,
|
||||
var,
|
||||
b,
|
||||
u,
|
||||
i,
|
||||
center,
|
||||
dl,
|
||||
dt,
|
||||
dd,
|
||||
ol,
|
||||
ul,
|
||||
li,
|
||||
fieldset,
|
||||
form,
|
||||
label,
|
||||
legend,
|
||||
table,
|
||||
caption,
|
||||
tbody,
|
||||
tfoot,
|
||||
thead,
|
||||
tr,
|
||||
th,
|
||||
td,
|
||||
article,
|
||||
aside,
|
||||
canvas,
|
||||
details,
|
||||
embed,
|
||||
figure,
|
||||
figcaption,
|
||||
footer,
|
||||
header,
|
||||
hgroup,
|
||||
menu,
|
||||
nav,
|
||||
output,
|
||||
ruby,
|
||||
section,
|
||||
summary,
|
||||
time,
|
||||
mark,
|
||||
audio,
|
||||
video {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
border: 0;
|
||||
font-size: 100%;
|
||||
font: inherit;
|
||||
vertical-align: baseline;
|
||||
}
|
||||
/* HTML5 display-role reset for older browsers */
|
||||
article,
|
||||
aside,
|
||||
details,
|
||||
figcaption,
|
||||
figure,
|
||||
footer,
|
||||
header,
|
||||
hgroup,
|
||||
menu,
|
||||
nav,
|
||||
section {
|
||||
display: block;
|
||||
}
|
||||
body {
|
||||
line-height: 1;
|
||||
}
|
||||
ol,
|
||||
ul {
|
||||
list-style: none;
|
||||
}
|
||||
blockquote,
|
||||
q {
|
||||
quotes: none;
|
||||
}
|
||||
blockquote:before,
|
||||
blockquote:after,
|
||||
q:before,
|
||||
q:after {
|
||||
content: '';
|
||||
content: none;
|
||||
}
|
||||
table {
|
||||
border-collapse: collapse;
|
||||
border-spacing: 0;
|
||||
}
|
||||
1221
api/files/screen.css
1221
api/files/screen.css
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,211 +0,0 @@
|
|||
var appName;
|
||||
var popupMask;
|
||||
var popupDialog;
|
||||
var clientId;
|
||||
var realm;
|
||||
|
||||
function handleLogin() {
|
||||
var scopes = [];
|
||||
|
||||
if(window.swaggerUi.api.authSchemes
|
||||
&& window.swaggerUi.api.authSchemes.oauth2
|
||||
&& window.swaggerUi.api.authSchemes.oauth2.scopes) {
|
||||
scopes = window.swaggerUi.api.authSchemes.oauth2.scopes;
|
||||
}
|
||||
|
||||
if(window.swaggerUi.api
|
||||
&& window.swaggerUi.api.info) {
|
||||
appName = window.swaggerUi.api.info.title;
|
||||
}
|
||||
|
||||
if(popupDialog.length > 0)
|
||||
popupDialog = popupDialog.last();
|
||||
else {
|
||||
popupDialog = $(
|
||||
[
|
||||
'<div class="api-popup-dialog">',
|
||||
'<div class="api-popup-title">Select OAuth2.0 Scopes</div>',
|
||||
'<div class="api-popup-content">',
|
||||
'<p>Scopes are used to grant an application different levels of access to data on behalf of the end user. Each API may declare one or more scopes.',
|
||||
'<a href="#">Learn how to use</a>',
|
||||
'</p>',
|
||||
'<p><strong>' + appName + '</strong> API requires the following scopes. Select which ones you want to grant to Swagger UI.</p>',
|
||||
'<ul class="api-popup-scopes">',
|
||||
'</ul>',
|
||||
'<p class="error-msg"></p>',
|
||||
'<div class="api-popup-actions"><button class="api-popup-authbtn api-button green" type="button">Authorize</button><button class="api-popup-cancel api-button gray" type="button">Cancel</button></div>',
|
||||
'</div>',
|
||||
'</div>'].join(''));
|
||||
$(document.body).append(popupDialog);
|
||||
|
||||
popup = popupDialog.find('ul.api-popup-scopes').empty();
|
||||
for (i = 0; i < scopes.length; i ++) {
|
||||
scope = scopes[i];
|
||||
str = '<li><input type="checkbox" id="scope_' + i + '" scope="' + scope.scope + '"/>' + '<label for="scope_' + i + '">' + scope.scope;
|
||||
if (scope.description) {
|
||||
str += '<br/><span class="api-scope-desc">' + scope.description + '</span>';
|
||||
}
|
||||
str += '</label></li>';
|
||||
popup.append(str);
|
||||
}
|
||||
}
|
||||
|
||||
var $win = $(window),
|
||||
dw = $win.width(),
|
||||
dh = $win.height(),
|
||||
st = $win.scrollTop(),
|
||||
dlgWd = popupDialog.outerWidth(),
|
||||
dlgHt = popupDialog.outerHeight(),
|
||||
top = (dh -dlgHt)/2 + st,
|
||||
left = (dw - dlgWd)/2;
|
||||
|
||||
popupDialog.css({
|
||||
top: (top < 0? 0 : top) + 'px',
|
||||
left: (left < 0? 0 : left) + 'px'
|
||||
});
|
||||
|
||||
popupDialog.find('button.api-popup-cancel').click(function() {
|
||||
popupMask.hide();
|
||||
popupDialog.hide();
|
||||
});
|
||||
popupDialog.find('button.api-popup-authbtn').click(function() {
|
||||
popupMask.hide();
|
||||
popupDialog.hide();
|
||||
|
||||
var authSchemes = window.swaggerUi.api.authSchemes;
|
||||
var host = window.location;
|
||||
var redirectUrl = host.protocol + '//' + host.host + "/o2c.html";
|
||||
var url = null;
|
||||
|
||||
var p = window.swaggerUi.api.authSchemes;
|
||||
for (var key in p) {
|
||||
if (p.hasOwnProperty(key)) {
|
||||
var o = p[key].grantTypes;
|
||||
for(var t in o) {
|
||||
if(o.hasOwnProperty(t) && t === 'implicit') {
|
||||
var dets = o[t];
|
||||
url = dets.loginEndpoint.url + "?response_type=token";
|
||||
window.swaggerUi.tokenName = dets.tokenName;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
var scopes = []
|
||||
var o = $('.api-popup-scopes').find('input:checked');
|
||||
|
||||
for(k =0; k < o.length; k++) {
|
||||
scopes.push($(o[k]).attr("scope"));
|
||||
}
|
||||
|
||||
window.enabledScopes=scopes;
|
||||
|
||||
url += '&redirect_uri=' + encodeURIComponent(redirectUrl);
|
||||
url += '&realm=' + encodeURIComponent(realm);
|
||||
url += '&client_id=' + encodeURIComponent(clientId);
|
||||
url += '&scope=' + encodeURIComponent(scopes);
|
||||
|
||||
window.open(url);
|
||||
});
|
||||
|
||||
popupMask.show();
|
||||
popupDialog.show();
|
||||
return;
|
||||
}
|
||||
|
||||
|
||||
function handleLogout() {
|
||||
for(key in window.authorizations.authz){
|
||||
window.authorizations.remove(key)
|
||||
}
|
||||
window.enabledScopes = null;
|
||||
$('.api-ic.ic-on').addClass('ic-off');
|
||||
$('.api-ic.ic-on').removeClass('ic-on');
|
||||
|
||||
// set the info box
|
||||
$('.api-ic.ic-warning').addClass('ic-error');
|
||||
$('.api-ic.ic-warning').removeClass('ic-warning');
|
||||
}
|
||||
|
||||
function initOAuth(opts) {
|
||||
var o = (opts||{});
|
||||
var errors = [];
|
||||
|
||||
appName = (o.appName||errors.push("missing appName"));
|
||||
popupMask = (o.popupMask||$('#api-common-mask'));
|
||||
popupDialog = (o.popupDialog||$('.api-popup-dialog'));
|
||||
clientId = (o.clientId||errors.push("missing client id"));
|
||||
realm = (o.realm||errors.push("missing realm"));
|
||||
|
||||
if(errors.length > 0){
|
||||
log("auth unable initialize oauth: " + errors);
|
||||
return;
|
||||
}
|
||||
|
||||
$('pre code').each(function(i, e) {hljs.highlightBlock(e)});
|
||||
$('.api-ic').click(function(s) {
|
||||
if($(s.target).hasClass('ic-off'))
|
||||
handleLogin();
|
||||
else {
|
||||
handleLogout();
|
||||
}
|
||||
false;
|
||||
});
|
||||
}
|
||||
|
||||
function onOAuthComplete(token) {
|
||||
if(token) {
|
||||
if(token.error) {
|
||||
var checkbox = $('input[type=checkbox],.secured')
|
||||
checkbox.each(function(pos){
|
||||
checkbox[pos].checked = false;
|
||||
});
|
||||
alert(token.error);
|
||||
}
|
||||
else {
|
||||
var b = token[window.swaggerUi.tokenName];
|
||||
if(b){
|
||||
// if all roles are satisfied
|
||||
var o = null;
|
||||
$.each($('.auth #api_information_panel'), function(k, v) {
|
||||
var children = v;
|
||||
if(children && children.childNodes) {
|
||||
var requiredScopes = [];
|
||||
$.each((children.childNodes), function (k1, v1){
|
||||
var inner = v1.innerHTML;
|
||||
if(inner)
|
||||
requiredScopes.push(inner);
|
||||
});
|
||||
var diff = [];
|
||||
for(var i=0; i < requiredScopes.length; i++) {
|
||||
var s = requiredScopes[i];
|
||||
if(window.enabledScopes && window.enabledScopes.indexOf(s) == -1) {
|
||||
diff.push(s);
|
||||
}
|
||||
}
|
||||
if(diff.length > 0){
|
||||
o = v.parentNode;
|
||||
$(o.parentNode).find('.api-ic.ic-on').addClass('ic-off');
|
||||
$(o.parentNode).find('.api-ic.ic-on').removeClass('ic-on');
|
||||
|
||||
// sorry, not all scopes are satisfied
|
||||
$(o).find('.api-ic').addClass('ic-warning');
|
||||
$(o).find('.api-ic').removeClass('ic-error');
|
||||
}
|
||||
else {
|
||||
o = v.parentNode;
|
||||
$(o.parentNode).find('.api-ic.ic-off').addClass('ic-on');
|
||||
$(o.parentNode).find('.api-ic.ic-off').removeClass('ic-off');
|
||||
|
||||
// all scopes are satisfied
|
||||
$(o).find('.api-ic').addClass('ic-info');
|
||||
$(o).find('.api-ic').removeClass('ic-warning');
|
||||
$(o).find('.api-ic').removeClass('ic-error');
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
window.authorizations.add("oauth2", new ApiKeyAuthorization("Authorization", "Bearer " + b, "header"));
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
File diff suppressed because it is too large
Load diff
1604
api/files/swagger.js
1604
api/files/swagger.js
File diff suppressed because it is too large
Load diff
32
api/files/underscore-min.js
vendored
32
api/files/underscore-min.js
vendored
|
|
@ -1,32 +0,0 @@
|
|||
// Underscore.js 1.3.3
|
||||
// (c) 2009-2012 Jeremy Ashkenas, DocumentCloud Inc.
|
||||
// Underscore is freely distributable under the MIT license.
|
||||
// Portions of Underscore are inspired or borrowed from Prototype,
|
||||
// Oliver Steele's Functional, and John Resig's Micro-Templating.
|
||||
// For all details and documentation:
|
||||
// http://documentcloud.github.com/underscore
|
||||
(function(){function r(a,c,d){if(a===c)return 0!==a||1/a==1/c;if(null==a||null==c)return a===c;a._chain&&(a=a._wrapped);c._chain&&(c=c._wrapped);if(a.isEqual&&b.isFunction(a.isEqual))return a.isEqual(c);if(c.isEqual&&b.isFunction(c.isEqual))return c.isEqual(a);var e=l.call(a);if(e!=l.call(c))return!1;switch(e){case "[object String]":return a==""+c;case "[object Number]":return a!=+a?c!=+c:0==a?1/a==1/c:a==+c;case "[object Date]":case "[object Boolean]":return+a==+c;case "[object RegExp]":return a.source==
|
||||
c.source&&a.global==c.global&&a.multiline==c.multiline&&a.ignoreCase==c.ignoreCase}if("object"!=typeof a||"object"!=typeof c)return!1;for(var f=d.length;f--;)if(d[f]==a)return!0;d.push(a);var f=0,g=!0;if("[object Array]"==e){if(f=a.length,g=f==c.length)for(;f--&&(g=f in a==f in c&&r(a[f],c[f],d)););}else{if("constructor"in a!="constructor"in c||a.constructor!=c.constructor)return!1;for(var h in a)if(b.has(a,h)&&(f++,!(g=b.has(c,h)&&r(a[h],c[h],d))))break;if(g){for(h in c)if(b.has(c,h)&&!f--)break;
|
||||
g=!f}}d.pop();return g}var s=this,I=s._,o={},k=Array.prototype,p=Object.prototype,i=k.slice,J=k.unshift,l=p.toString,K=p.hasOwnProperty,y=k.forEach,z=k.map,A=k.reduce,B=k.reduceRight,C=k.filter,D=k.every,E=k.some,q=k.indexOf,F=k.lastIndexOf,p=Array.isArray,L=Object.keys,t=Function.prototype.bind,b=function(a){return new m(a)};"undefined"!==typeof exports?("undefined"!==typeof module&&module.exports&&(exports=module.exports=b),exports._=b):s._=b;b.VERSION="1.3.3";var j=b.each=b.forEach=function(a,
|
||||
c,d){if(a!=null)if(y&&a.forEach===y)a.forEach(c,d);else if(a.length===+a.length)for(var e=0,f=a.length;e<f;e++){if(e in a&&c.call(d,a[e],e,a)===o)break}else for(e in a)if(b.has(a,e)&&c.call(d,a[e],e,a)===o)break};b.map=b.collect=function(a,c,b){var e=[];if(a==null)return e;if(z&&a.map===z)return a.map(c,b);j(a,function(a,g,h){e[e.length]=c.call(b,a,g,h)});if(a.length===+a.length)e.length=a.length;return e};b.reduce=b.foldl=b.inject=function(a,c,d,e){var f=arguments.length>2;a==null&&(a=[]);if(A&&
|
||||
a.reduce===A){e&&(c=b.bind(c,e));return f?a.reduce(c,d):a.reduce(c)}j(a,function(a,b,i){if(f)d=c.call(e,d,a,b,i);else{d=a;f=true}});if(!f)throw new TypeError("Reduce of empty array with no initial value");return d};b.reduceRight=b.foldr=function(a,c,d,e){var f=arguments.length>2;a==null&&(a=[]);if(B&&a.reduceRight===B){e&&(c=b.bind(c,e));return f?a.reduceRight(c,d):a.reduceRight(c)}var g=b.toArray(a).reverse();e&&!f&&(c=b.bind(c,e));return f?b.reduce(g,c,d,e):b.reduce(g,c)};b.find=b.detect=function(a,
|
||||
c,b){var e;G(a,function(a,g,h){if(c.call(b,a,g,h)){e=a;return true}});return e};b.filter=b.select=function(a,c,b){var e=[];if(a==null)return e;if(C&&a.filter===C)return a.filter(c,b);j(a,function(a,g,h){c.call(b,a,g,h)&&(e[e.length]=a)});return e};b.reject=function(a,c,b){var e=[];if(a==null)return e;j(a,function(a,g,h){c.call(b,a,g,h)||(e[e.length]=a)});return e};b.every=b.all=function(a,c,b){var e=true;if(a==null)return e;if(D&&a.every===D)return a.every(c,b);j(a,function(a,g,h){if(!(e=e&&c.call(b,
|
||||
a,g,h)))return o});return!!e};var G=b.some=b.any=function(a,c,d){c||(c=b.identity);var e=false;if(a==null)return e;if(E&&a.some===E)return a.some(c,d);j(a,function(a,b,h){if(e||(e=c.call(d,a,b,h)))return o});return!!e};b.include=b.contains=function(a,c){var b=false;if(a==null)return b;if(q&&a.indexOf===q)return a.indexOf(c)!=-1;return b=G(a,function(a){return a===c})};b.invoke=function(a,c){var d=i.call(arguments,2);return b.map(a,function(a){return(b.isFunction(c)?c||a:a[c]).apply(a,d)})};b.pluck=
|
||||
function(a,c){return b.map(a,function(a){return a[c]})};b.max=function(a,c,d){if(!c&&b.isArray(a)&&a[0]===+a[0])return Math.max.apply(Math,a);if(!c&&b.isEmpty(a))return-Infinity;var e={computed:-Infinity};j(a,function(a,b,h){b=c?c.call(d,a,b,h):a;b>=e.computed&&(e={value:a,computed:b})});return e.value};b.min=function(a,c,d){if(!c&&b.isArray(a)&&a[0]===+a[0])return Math.min.apply(Math,a);if(!c&&b.isEmpty(a))return Infinity;var e={computed:Infinity};j(a,function(a,b,h){b=c?c.call(d,a,b,h):a;b<e.computed&&
|
||||
(e={value:a,computed:b})});return e.value};b.shuffle=function(a){var b=[],d;j(a,function(a,f){d=Math.floor(Math.random()*(f+1));b[f]=b[d];b[d]=a});return b};b.sortBy=function(a,c,d){var e=b.isFunction(c)?c:function(a){return a[c]};return b.pluck(b.map(a,function(a,b,c){return{value:a,criteria:e.call(d,a,b,c)}}).sort(function(a,b){var c=a.criteria,d=b.criteria;return c===void 0?1:d===void 0?-1:c<d?-1:c>d?1:0}),"value")};b.groupBy=function(a,c){var d={},e=b.isFunction(c)?c:function(a){return a[c]};
|
||||
j(a,function(a,b){var c=e(a,b);(d[c]||(d[c]=[])).push(a)});return d};b.sortedIndex=function(a,c,d){d||(d=b.identity);for(var e=0,f=a.length;e<f;){var g=e+f>>1;d(a[g])<d(c)?e=g+1:f=g}return e};b.toArray=function(a){return!a?[]:b.isArray(a)||b.isArguments(a)?i.call(a):a.toArray&&b.isFunction(a.toArray)?a.toArray():b.values(a)};b.size=function(a){return b.isArray(a)?a.length:b.keys(a).length};b.first=b.head=b.take=function(a,b,d){return b!=null&&!d?i.call(a,0,b):a[0]};b.initial=function(a,b,d){return i.call(a,
|
||||
0,a.length-(b==null||d?1:b))};b.last=function(a,b,d){return b!=null&&!d?i.call(a,Math.max(a.length-b,0)):a[a.length-1]};b.rest=b.tail=function(a,b,d){return i.call(a,b==null||d?1:b)};b.compact=function(a){return b.filter(a,function(a){return!!a})};b.flatten=function(a,c){return b.reduce(a,function(a,e){if(b.isArray(e))return a.concat(c?e:b.flatten(e));a[a.length]=e;return a},[])};b.without=function(a){return b.difference(a,i.call(arguments,1))};b.uniq=b.unique=function(a,c,d){var d=d?b.map(a,d):a,
|
||||
e=[];a.length<3&&(c=true);b.reduce(d,function(d,g,h){if(c?b.last(d)!==g||!d.length:!b.include(d,g)){d.push(g);e.push(a[h])}return d},[]);return e};b.union=function(){return b.uniq(b.flatten(arguments,true))};b.intersection=b.intersect=function(a){var c=i.call(arguments,1);return b.filter(b.uniq(a),function(a){return b.every(c,function(c){return b.indexOf(c,a)>=0})})};b.difference=function(a){var c=b.flatten(i.call(arguments,1),true);return b.filter(a,function(a){return!b.include(c,a)})};b.zip=function(){for(var a=
|
||||
i.call(arguments),c=b.max(b.pluck(a,"length")),d=Array(c),e=0;e<c;e++)d[e]=b.pluck(a,""+e);return d};b.indexOf=function(a,c,d){if(a==null)return-1;var e;if(d){d=b.sortedIndex(a,c);return a[d]===c?d:-1}if(q&&a.indexOf===q)return a.indexOf(c);d=0;for(e=a.length;d<e;d++)if(d in a&&a[d]===c)return d;return-1};b.lastIndexOf=function(a,b){if(a==null)return-1;if(F&&a.lastIndexOf===F)return a.lastIndexOf(b);for(var d=a.length;d--;)if(d in a&&a[d]===b)return d;return-1};b.range=function(a,b,d){if(arguments.length<=
|
||||
1){b=a||0;a=0}for(var d=arguments[2]||1,e=Math.max(Math.ceil((b-a)/d),0),f=0,g=Array(e);f<e;){g[f++]=a;a=a+d}return g};var H=function(){};b.bind=function(a,c){var d,e;if(a.bind===t&&t)return t.apply(a,i.call(arguments,1));if(!b.isFunction(a))throw new TypeError;e=i.call(arguments,2);return d=function(){if(!(this instanceof d))return a.apply(c,e.concat(i.call(arguments)));H.prototype=a.prototype;var b=new H,g=a.apply(b,e.concat(i.call(arguments)));return Object(g)===g?g:b}};b.bindAll=function(a){var c=
|
||||
i.call(arguments,1);c.length==0&&(c=b.functions(a));j(c,function(c){a[c]=b.bind(a[c],a)});return a};b.memoize=function(a,c){var d={};c||(c=b.identity);return function(){var e=c.apply(this,arguments);return b.has(d,e)?d[e]:d[e]=a.apply(this,arguments)}};b.delay=function(a,b){var d=i.call(arguments,2);return setTimeout(function(){return a.apply(null,d)},b)};b.defer=function(a){return b.delay.apply(b,[a,1].concat(i.call(arguments,1)))};b.throttle=function(a,c){var d,e,f,g,h,i,j=b.debounce(function(){h=
|
||||
g=false},c);return function(){d=this;e=arguments;f||(f=setTimeout(function(){f=null;h&&a.apply(d,e);j()},c));g?h=true:i=a.apply(d,e);j();g=true;return i}};b.debounce=function(a,b,d){var e;return function(){var f=this,g=arguments;d&&!e&&a.apply(f,g);clearTimeout(e);e=setTimeout(function(){e=null;d||a.apply(f,g)},b)}};b.once=function(a){var b=false,d;return function(){if(b)return d;b=true;return d=a.apply(this,arguments)}};b.wrap=function(a,b){return function(){var d=[a].concat(i.call(arguments,0));
|
||||
return b.apply(this,d)}};b.compose=function(){var a=arguments;return function(){for(var b=arguments,d=a.length-1;d>=0;d--)b=[a[d].apply(this,b)];return b[0]}};b.after=function(a,b){return a<=0?b():function(){if(--a<1)return b.apply(this,arguments)}};b.keys=L||function(a){if(a!==Object(a))throw new TypeError("Invalid object");var c=[],d;for(d in a)b.has(a,d)&&(c[c.length]=d);return c};b.values=function(a){return b.map(a,b.identity)};b.functions=b.methods=function(a){var c=[],d;for(d in a)b.isFunction(a[d])&&
|
||||
c.push(d);return c.sort()};b.extend=function(a){j(i.call(arguments,1),function(b){for(var d in b)a[d]=b[d]});return a};b.pick=function(a){var c={};j(b.flatten(i.call(arguments,1)),function(b){b in a&&(c[b]=a[b])});return c};b.defaults=function(a){j(i.call(arguments,1),function(b){for(var d in b)a[d]==null&&(a[d]=b[d])});return a};b.clone=function(a){return!b.isObject(a)?a:b.isArray(a)?a.slice():b.extend({},a)};b.tap=function(a,b){b(a);return a};b.isEqual=function(a,b){return r(a,b,[])};b.isEmpty=
|
||||
function(a){if(a==null)return true;if(b.isArray(a)||b.isString(a))return a.length===0;for(var c in a)if(b.has(a,c))return false;return true};b.isElement=function(a){return!!(a&&a.nodeType==1)};b.isArray=p||function(a){return l.call(a)=="[object Array]"};b.isObject=function(a){return a===Object(a)};b.isArguments=function(a){return l.call(a)=="[object Arguments]"};b.isArguments(arguments)||(b.isArguments=function(a){return!(!a||!b.has(a,"callee"))});b.isFunction=function(a){return l.call(a)=="[object Function]"};
|
||||
b.isString=function(a){return l.call(a)=="[object String]"};b.isNumber=function(a){return l.call(a)=="[object Number]"};b.isFinite=function(a){return b.isNumber(a)&&isFinite(a)};b.isNaN=function(a){return a!==a};b.isBoolean=function(a){return a===true||a===false||l.call(a)=="[object Boolean]"};b.isDate=function(a){return l.call(a)=="[object Date]"};b.isRegExp=function(a){return l.call(a)=="[object RegExp]"};b.isNull=function(a){return a===null};b.isUndefined=function(a){return a===void 0};b.has=function(a,
|
||||
b){return K.call(a,b)};b.noConflict=function(){s._=I;return this};b.identity=function(a){return a};b.times=function(a,b,d){for(var e=0;e<a;e++)b.call(d,e)};b.escape=function(a){return(""+a).replace(/&/g,"&").replace(/</g,"<").replace(/>/g,">").replace(/"/g,""").replace(/'/g,"'").replace(/\//g,"/")};b.result=function(a,c){if(a==null)return null;var d=a[c];return b.isFunction(d)?d.call(a):d};b.mixin=function(a){j(b.functions(a),function(c){M(c,b[c]=a[c])})};var N=0;b.uniqueId=
|
||||
function(a){var b=N++;return a?a+b:b};b.templateSettings={evaluate:/<%([\s\S]+?)%>/g,interpolate:/<%=([\s\S]+?)%>/g,escape:/<%-([\s\S]+?)%>/g};var u=/.^/,n={"\\":"\\","'":"'",r:"\r",n:"\n",t:"\t",u2028:"\u2028",u2029:"\u2029"},v;for(v in n)n[n[v]]=v;var O=/\\|'|\r|\n|\t|\u2028|\u2029/g,P=/\\(\\|'|r|n|t|u2028|u2029)/g,w=function(a){return a.replace(P,function(a,b){return n[b]})};b.template=function(a,c,d){d=b.defaults(d||{},b.templateSettings);a="__p+='"+a.replace(O,function(a){return"\\"+n[a]}).replace(d.escape||
|
||||
u,function(a,b){return"'+\n_.escape("+w(b)+")+\n'"}).replace(d.interpolate||u,function(a,b){return"'+\n("+w(b)+")+\n'"}).replace(d.evaluate||u,function(a,b){return"';\n"+w(b)+"\n;__p+='"})+"';\n";d.variable||(a="with(obj||{}){\n"+a+"}\n");var a="var __p='';var print=function(){__p+=Array.prototype.join.call(arguments, '')};\n"+a+"return __p;\n",e=new Function(d.variable||"obj","_",a);if(c)return e(c,b);c=function(a){return e.call(this,a,b)};c.source="function("+(d.variable||"obj")+"){\n"+a+"}";return c};
|
||||
b.chain=function(a){return b(a).chain()};var m=function(a){this._wrapped=a};b.prototype=m.prototype;var x=function(a,c){return c?b(a).chain():a},M=function(a,c){m.prototype[a]=function(){var a=i.call(arguments);J.call(a,this._wrapped);return x(c.apply(b,a),this._chain)}};b.mixin(b);j("pop,push,reverse,shift,sort,splice,unshift".split(","),function(a){var b=k[a];m.prototype[a]=function(){var d=this._wrapped;b.apply(d,arguments);var e=d.length;(a=="shift"||a=="splice")&&e===0&&delete d[0];return x(d,
|
||||
this._chain)}});j(["concat","join","slice"],function(a){var b=k[a];m.prototype[a]=function(){return x(b.apply(this._wrapped,arguments),this._chain)}});m.prototype.chain=function(){this._chain=true;return this};m.prototype.value=function(){return this._wrapped}}).call(this);
|
||||
|
|
@ -242,6 +242,130 @@ footer {
|
|||
}
|
||||
}
|
||||
|
||||
/* Styles for sections that are rendered from data, such as HTTP APIs and event schemas */
|
||||
.rendered-data {
|
||||
margin: 1rem 0 3rem 0;
|
||||
padding: 1rem;
|
||||
|
||||
details {
|
||||
|
||||
summary {
|
||||
padding: .5rem 0;
|
||||
list-style-position: outside;
|
||||
}
|
||||
}
|
||||
|
||||
.deprecated-inline {
|
||||
|
||||
&:after {
|
||||
content: " — DEPRECATED";
|
||||
color: $warning;
|
||||
font-weight: $font-weight-bold;
|
||||
}
|
||||
}
|
||||
|
||||
h1 {
|
||||
display: inline-block;
|
||||
font-size: 1.3rem;
|
||||
|
||||
.endpoint {
|
||||
color: $secondary;
|
||||
}
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-weight: $font-weight-bold;
|
||||
font-size: 1.3rem;
|
||||
margin: 3rem 0 .5rem 0;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-weight: $font-weight-bold;
|
||||
font-size: 1.1rem;
|
||||
margin: 1.5rem 0 .75rem 0;
|
||||
}
|
||||
|
||||
h2 + table, h3 + table, h3 + div.highlight {
|
||||
margin-top: 0;
|
||||
}
|
||||
|
||||
hr {
|
||||
border-bottom: 2px solid $dark;
|
||||
margin-bottom: 1.5rem;
|
||||
}
|
||||
|
||||
p {
|
||||
margin: .5rem;
|
||||
max-width: 80%;
|
||||
}
|
||||
|
||||
p code, table code {
|
||||
background-color: $white;
|
||||
}
|
||||
|
||||
table {
|
||||
table-layout: fixed;
|
||||
width: 100%;
|
||||
margin: 4rem 0;
|
||||
|
||||
caption {
|
||||
caption-side: top;
|
||||
color: $dark;
|
||||
font-size: 1rem;
|
||||
font-weight: $font-weight-bold;
|
||||
}
|
||||
|
||||
th, td, caption {
|
||||
padding: 1rem;
|
||||
}
|
||||
|
||||
th {
|
||||
background-color: $white;
|
||||
}
|
||||
|
||||
caption, tr {
|
||||
background-color: $table-row-default;
|
||||
}
|
||||
|
||||
tr:nth-child(even) {
|
||||
background-color: $table-row-alternate;
|
||||
}
|
||||
|
||||
&.basic-info, &.basic-info th, &.basic-info td {
|
||||
table-layout: fixed;
|
||||
margin: 1rem 0 .5rem 0;
|
||||
background-color: $white;
|
||||
}
|
||||
|
||||
&.basic-info th {
|
||||
width: 15rem;
|
||||
}
|
||||
|
||||
.col-name, .col-type, .col-status {
|
||||
width: 25%;
|
||||
}
|
||||
|
||||
.col-description {
|
||||
width: 50%;
|
||||
}
|
||||
|
||||
.col-status-description {
|
||||
width: 75%;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
pre {
|
||||
border: 0;
|
||||
border-left: solid 5px $secondary;
|
||||
}
|
||||
|
||||
.http-api-method {
|
||||
font-weight: $font-weight-bold;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
/* Miscellaneous custom bits */
|
||||
|
||||
/* Update link colours for MAtrix style */
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ NOT alter (e.g. add more) events they were going to send within that
|
|||
transaction ID on retries, as the application service may have already
|
||||
processed the events.
|
||||
|
||||
{{transactions\_as\_http\_api}}
|
||||
{{% http-api spec="application-service" api="transactions" %}}
|
||||
|
||||
#### Querying
|
||||
|
||||
|
|
@ -227,9 +227,9 @@ about information about the entity such as room ID to room alias
|
|||
mappings.
|
||||
{{% /boxes/rationale %}}
|
||||
|
||||
{{query\_user\_as\_http\_api}}
|
||||
{{% http-api spec="application-service" api="query_user" %}}
|
||||
|
||||
{{query\_room\_as\_http\_api}}
|
||||
{{% http-api spec="application-service" api="query_room" %}}
|
||||
|
||||
#### Third party networks
|
||||
|
||||
|
|
@ -251,7 +251,7 @@ request the homeserver to search in a particular "network" (protocol),
|
|||
the search fields will be passed along to the application service for
|
||||
filtering.
|
||||
|
||||
{{protocols\_as\_http\_api}}
|
||||
{{% http-api spec="application-service" api="protocols" %}}
|
||||
|
||||
### Client-Server API Extensions
|
||||
|
||||
|
|
@ -356,7 +356,7 @@ defined third party protocols. These room directories may be accessed by
|
|||
clients through additional parameters on the `/publicRooms`
|
||||
client-server endpoint.
|
||||
|
||||
{{appservice\_room\_directory\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="appservice_room_directory" %}}
|
||||
|
||||
### Referencing messages from a third party network
|
||||
|
||||
|
|
|
|||
|
|
@ -205,7 +205,7 @@ Some API endpoints may allow or require the use of `POST` requests
|
|||
without a transaction ID. Where this is optional, the use of a `PUT`
|
||||
request is strongly recommended.
|
||||
|
||||
{{versions\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="versions" %}}
|
||||
|
||||
## Web Browser Clients
|
||||
|
||||
|
|
@ -287,7 +287,7 @@ specify parameter values. The flow for this method is as follows:
|
|||
1. Parse it as a URL. If it is not a URL, then `FAIL_ERROR`.
|
||||
2. Clients SHOULD validate that the URL points to a valid
|
||||
homeserver before accepting it by connecting to the
|
||||
`/_matrix/client/versions`\_ endpoint, ensuring that it does
|
||||
[`/_matrix/client/versions`](/client-server-api/#get_matrixclientversions) endpoint, ensuring that it does
|
||||
not return an error, and parsing and validating that the
|
||||
data conforms with the expected response format. If any step
|
||||
in the validation fails, then `FAIL_ERROR`. Validation is
|
||||
|
|
@ -301,7 +301,7 @@ specify parameter values. The flow for this method is as follows:
|
|||
`m.identity_server` property is present, but does not have a
|
||||
`base_url` value, then `FAIL_ERROR`.
|
||||
|
||||
{{wellknown\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="wellknown" %}}
|
||||
|
||||
## Client Authentication
|
||||
|
||||
|
|
@ -1021,9 +1021,9 @@ client supports it, the client should redirect the user to the
|
|||
is complete, the client will need to submit a `/login` request matching
|
||||
`m.login.token`.
|
||||
|
||||
{{login\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="login" %}}
|
||||
|
||||
{{logout\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="logout" %}}
|
||||
|
||||
#### Login Fallback
|
||||
|
||||
|
|
@ -1044,7 +1044,7 @@ the login endpoint during the login process. For example:
|
|||
|
||||
### Account registration and management
|
||||
|
||||
{{registration\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="registration" %}}
|
||||
|
||||
#### Notes on password management
|
||||
|
||||
|
|
@ -1069,11 +1069,11 @@ identifier that is found in an identity server. Note that an identifier
|
|||
can be added and bound at the same time, depending on context.
|
||||
{{% /boxes/note %}}
|
||||
|
||||
{{administrative\_contact\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="administrative_contact" %}}
|
||||
|
||||
### Current account information
|
||||
|
||||
{{whoami\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="whoami" %}}
|
||||
|
||||
#### Notes on identity servers
|
||||
|
||||
|
|
@ -1111,7 +1111,7 @@ which has no `m.identity_server` account data event should not end up
|
|||
with the client's default identity server in their account data, unless
|
||||
the user first visits their account settings to set the identity server.
|
||||
|
||||
{{m\_identity\_server\_event}}
|
||||
{{% event event="m.identity_server" %}}
|
||||
|
||||
## Capabilities negotiation
|
||||
|
||||
|
|
@ -1148,7 +1148,7 @@ Matrix specification while other values may be used by servers using the
|
|||
Java package naming convention. The capabilities supported by the Matrix
|
||||
specification are defined later in this section.
|
||||
|
||||
{{capabilities\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="capabilities" %}}
|
||||
|
||||
### `m.change_password` capability
|
||||
|
||||
|
|
@ -1350,13 +1350,13 @@ The expected pattern for using lazy-loading is currently:
|
|||
|
||||
The current endpoints which support lazy-loading room members are:
|
||||
|
||||
- `/sync`\_
|
||||
- `/rooms/<room_id>/messages`\_
|
||||
- `/rooms/{roomId}/context/{eventId}`\_
|
||||
- [`/sync`](/client-server-api/#get_matrixclientr0sync)
|
||||
- [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientr0roomsroomidmessages)
|
||||
- [`/rooms/{roomId}/context/{eventId}`](/client-server-api/#get_matrixclientr0roomsroomidcontexteventid)
|
||||
|
||||
### API endpoints
|
||||
|
||||
{{filter\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="filter" %}}
|
||||
|
||||
## Events
|
||||
|
||||
|
|
@ -1385,14 +1385,12 @@ available room versions.
|
|||
|
||||
Room events are split into two categories:
|
||||
|
||||
State Events
|
||||
These are events which update the metadata state of the room (e.g. room
|
||||
* **State events**: These are events which update the metadata state of the room (e.g. room
|
||||
topic, room membership etc). State is keyed by a tuple of event `type`
|
||||
and a `state_key`. State in the room with the same key-tuple will be
|
||||
overwritten.
|
||||
|
||||
Message events
|
||||
These are events which describe transient "once-off" activity in a room:
|
||||
* **Message events**: These are events which describe transient "once-off" activity in a room:
|
||||
typically communication such as sending an instant message or setting up
|
||||
a VoIP call.
|
||||
|
||||
|
|
@ -1416,11 +1414,15 @@ assuming the client has access to the `com.example` namespace.
|
|||
Note that the structure of these events may be different than those in
|
||||
the server-server API.
|
||||
|
||||
{{common\_event\_fields}}
|
||||
#### Event fields
|
||||
|
||||
{{common\_room\_event\_fields}}
|
||||
{{% event-fields event_type="event" %}}
|
||||
|
||||
#### State Event Fields
|
||||
#### Room event fields
|
||||
|
||||
{{% event-fields event_type="room_event" %}}
|
||||
|
||||
#### State event fields
|
||||
|
||||
In addition to the fields of a Room Event, State Events have the
|
||||
following fields.
|
||||
|
|
@ -1460,15 +1462,15 @@ This section is a work in progress.
|
|||
This specification outlines several standard event types, all of which
|
||||
are prefixed with `m.`
|
||||
|
||||
{{m\_room\_canonical\_alias\_event}}
|
||||
{{% event event="m.room.canonical_alias" %}}
|
||||
|
||||
{{m\_room\_create\_event}}
|
||||
{{% event event="m.room.create" %}}
|
||||
|
||||
{{m\_room\_join\_rules\_event}}
|
||||
{{% event event="m.room.join_rules" %}}
|
||||
|
||||
{{m\_room\_member\_event}}
|
||||
{{% event event="m.room.member" %}}
|
||||
|
||||
{{m\_room\_power\_levels\_event}}
|
||||
{{% event event="m.room.power_levels" %}}
|
||||
|
||||
#### Historical events
|
||||
|
||||
|
|
@ -1484,13 +1486,13 @@ events.
|
|||
### Syncing
|
||||
|
||||
To read events, the intended flow of operation is for clients to first
|
||||
call the `/sync`\_ API without a `since` parameter. This returns the
|
||||
call the [`/sync`](/client-server-api/#get_matrixclientr0sync) API without a `since` parameter. This returns the
|
||||
most recent message events for each room, as well as the state of the
|
||||
room at the start of the returned timeline. The response also includes a
|
||||
`next_batch` field, which should be used as the value of the `since`
|
||||
parameter in the next call to `/sync`. Finally, the response includes,
|
||||
for each room, a `prev_batch` field, which can be passed as a `start`
|
||||
parameter to the `/rooms/<room_id>/messages`\_ API to retrieve earlier
|
||||
parameter to the [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientr0roomsroomidmessages) API to retrieve earlier
|
||||
messages.
|
||||
|
||||
You can visualise the range of events being returned as:
|
||||
|
|
@ -1527,7 +1529,7 @@ containing only the most recent message events. A state "delta" is also
|
|||
returned, summarising any state changes in the omitted part of the
|
||||
timeline. The client may therefore end up with "gaps" in its knowledge
|
||||
of the message timeline. The client can fill these gaps using the
|
||||
`/rooms/<room_id>/messages`\_ API. This situation looks like this:
|
||||
[`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientr0roomsroomidmessages) API. This situation looks like this:
|
||||
|
||||
```
|
||||
| gap |
|
||||
|
|
@ -1582,23 +1584,23 @@ take a copy of the state dictionary, and *rewind* S1, in order to
|
|||
correctly calculate the display name for M0.
|
||||
{{% /boxes/rationale %}}
|
||||
|
||||
{{sync\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="sync" %}}
|
||||
|
||||
{{old\_sync\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="old_sync" %}}
|
||||
|
||||
### Getting events for a room
|
||||
|
||||
There are several APIs provided to `GET` events for a room:
|
||||
|
||||
{{rooms\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="rooms" %}}
|
||||
|
||||
{{message\_pagination\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="message_pagination" %}}
|
||||
|
||||
{{room\_initial\_sync\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="room_initial_sync" %}}
|
||||
|
||||
### Sending events to a room
|
||||
|
||||
{{room\_state\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="room_state" %}}
|
||||
|
||||
**Examples**
|
||||
|
||||
|
|
@ -1647,7 +1649,7 @@ PUT /rooms/!roomid:domain/state/m.room.bgd.color
|
|||
{ "color": "red", "hex": "#ff0000" }
|
||||
```
|
||||
|
||||
{{room\_send\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="room_send" %}}
|
||||
|
||||
### Redactions
|
||||
|
||||
|
|
@ -1682,11 +1684,11 @@ the topic to be removed from the room.
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_room\_redaction\_event}}
|
||||
{{% event event="m.room.redaction" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
{{redaction\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="redaction" %}}
|
||||
|
||||
## Rooms
|
||||
|
||||
|
|
@ -1706,7 +1708,7 @@ permissions in this room. This includes:
|
|||
See [Room Events](#room-events) for more information on these events. To
|
||||
create a room, a client has to use the following API.
|
||||
|
||||
{{create\_room\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="create_room" %}}
|
||||
|
||||
### Room aliases
|
||||
|
||||
|
|
@ -1731,7 +1733,7 @@ have a room alias of `#alias:example.com`, this SHOULD be checked to
|
|||
make sure that the room's ID matches the `room_id` returned from the
|
||||
request.
|
||||
|
||||
{{directory\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="directory" %}}
|
||||
|
||||
### Permissions
|
||||
|
||||
|
|
@ -1816,13 +1818,13 @@ The allowable state transitions of membership are:
|
|||
/ban
|
||||
```
|
||||
|
||||
{{list\_joined\_rooms\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="list_joined_rooms" %}}
|
||||
|
||||
#### Joining rooms
|
||||
|
||||
{{inviting\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="inviting" %}}
|
||||
|
||||
{{joining\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="joining" %}}
|
||||
|
||||
#### Leaving rooms
|
||||
|
||||
|
|
@ -1830,7 +1832,7 @@ A user can leave a room to stop receiving events for that room. A user
|
|||
must have been invited to or have joined the room before they are
|
||||
eligible to leave the room. Leaving a room to which the user has been
|
||||
invited rejects the invite. Once a user leaves a room, it will no longer
|
||||
appear in the response to the `/sync`\_ API unless it is explicitly
|
||||
appear in the response to the [`/sync`](/client-server-api/#get_matrixclientr0sync) API unless it is explicitly
|
||||
requested via a filter with the `include_leave` field set to `true`.
|
||||
|
||||
Whether or not they actually joined the room, if the room is an
|
||||
|
|
@ -1838,7 +1840,7 @@ Whether or not they actually joined the room, if the room is an
|
|||
re-join the room.
|
||||
|
||||
A user can also forget a room which they have left. Rooms which have
|
||||
been forgotten will never appear the response to the `/sync`\_ API,
|
||||
been forgotten will never appear the response to the [`/sync`](/client-server-api/#get_matrixclientr0sync) API,
|
||||
until the user re-joins or is re-invited.
|
||||
|
||||
A user may wish to force another user to leave a room. This can be done
|
||||
|
|
@ -1848,9 +1850,9 @@ behaviour is the same as if they had left of their own accord. In
|
|||
particular, the user is free to re-join if the room is not
|
||||
"invite-only".
|
||||
|
||||
{{leaving\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="leaving" %}}
|
||||
|
||||
{{kicking\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="kicking" %}}
|
||||
|
||||
##### Banning users in a room
|
||||
|
||||
|
|
@ -1859,7 +1861,7 @@ target user to leave the room and prevents them from re-joining the
|
|||
room. A banned user will not be treated as a joined user, and so will
|
||||
not be able to send or receive events in the room. In order to ban
|
||||
someone, the user performing the ban MUST have the required power level.
|
||||
To ban a user, a request should be made to `/rooms/<room_id>/ban`\_
|
||||
To ban a user, a request should be made to [`/rooms/<room_id>/ban`](/client-server-api/#post_matrixclientr0roomsroomidban)
|
||||
with:
|
||||
|
||||
```json
|
||||
|
|
@ -1881,24 +1883,24 @@ target member's state, by making a request to
|
|||
```
|
||||
|
||||
A user must be explicitly unbanned with a request to
|
||||
`/rooms/<room_id>/unban`\_ before they can re-join the room or be
|
||||
[`/rooms/<room_id>/unban`](/client-server-api/#post_matrixclientr0roomsroomidunban) before they can re-join the room or be
|
||||
re-invited.
|
||||
|
||||
{{banning\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="banning" %}}
|
||||
|
||||
### Listing rooms
|
||||
|
||||
{{list\_public\_rooms\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="list_public_rooms" %}}
|
||||
|
||||
## User Data
|
||||
|
||||
### User Directory
|
||||
|
||||
{{users\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="users" %}}
|
||||
|
||||
### Profiles
|
||||
|
||||
{{profile\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="profile" %}}
|
||||
|
||||
#### Events on Change of Profile Information
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ These events can also be received in a `/events` response or in the
|
|||
|
||||
#### Client Behaviour
|
||||
|
||||
{{account\_data\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="account-data" %}}
|
||||
|
||||
#### Server Behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -10,4 +10,4 @@ server state and data.
|
|||
|
||||
#### Client Behaviour
|
||||
|
||||
{{admin\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="admin" %}}
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ look like:
|
|||
|
||||
Clients can upload and download content using the following HTTP APIs.
|
||||
|
||||
{{content\_repo\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="content-repo" %}}
|
||||
|
||||
##### Thumbnails
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Clients that implement this module should offer the user a list of
|
|||
registered devices, as well as the means to update their display names.
|
||||
Clients should also allow users to delete disused devices.
|
||||
|
||||
{{device\_management\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="device_management" %}}
|
||||
|
||||
#### Security considerations
|
||||
|
||||
|
|
|
|||
|
|
@ -19,12 +19,12 @@ whether a chat is 'direct' to an invitee.
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_direct\_event}}
|
||||
{{% event event="m.direct" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
To start a direct chat with another user, the inviting user's client
|
||||
should set the `is_direct` flag to \_. The client should do this
|
||||
should set the `is_direct` flag to [`/createRoom`](/client-server-api/#post_matrixclientr0createroom). The client should do this
|
||||
whenever the flow the user has followed is one where their intention is
|
||||
to speak directly with another person, as opposed to bringing that
|
||||
person in to a shared room. For example, clicking on 'Start Chat' beside
|
||||
|
|
@ -38,10 +38,10 @@ the flag altogether.
|
|||
|
||||
Both the inviting client and the invitee's client should record the fact
|
||||
that the room is a direct chat by storing an `m.direct` event in the
|
||||
account data using \_.
|
||||
account data using [`/user/<user_id>/account_data/<type>`](/client-server-api/#put_matrixclientr0useruseridaccount_datatype).
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
When the `is_direct` flag is given to \_, the home server must set the
|
||||
When the `is_direct` flag is given to [`/createRoom`](/client-server-api/#post_matrixclientr0createroom), the home server must set the
|
||||
`is_direct` flag in the invite member event for any users invited in the
|
||||
\_ call.
|
||||
[`/createRoom`](/client-server-api/#post_matrixclientr0createroom) call.
|
||||
|
|
|
|||
|
|
@ -113,13 +113,13 @@ key, and a number of signed Curve25519 one-time keys.
|
|||
##### Uploading keys
|
||||
|
||||
A device uploads the public parts of identity keys to their homeserver
|
||||
as a signed JSON object, using the `/keys/upload`\_ API. The JSON object
|
||||
as a signed JSON object, using the [`/keys/upload`](/client-server-api/#post_matrixclientr0keysupload) API. The JSON object
|
||||
must include the public part of the device's Ed25519 key, and must be
|
||||
signed by that key, as described in [Signing
|
||||
JSON](/appendices/#signing-json).
|
||||
|
||||
One-time keys are also uploaded to the homeserver using the
|
||||
`/keys/upload`\_ API.
|
||||
[`/keys/upload`](/client-server-api/#post_matrixclientr0keysupload) API.
|
||||
|
||||
Devices must store the private part of each key they upload. They can
|
||||
discard the private part of a one-time key when they receive a message
|
||||
|
|
@ -134,12 +134,12 @@ too many private keys may discard keys starting with the oldest.
|
|||
Before Alice can send an encrypted message to Bob, she needs a list of
|
||||
each of his devices and the associated identity keys, so that she can
|
||||
establish an encryption session with each device. This list can be
|
||||
obtained by calling `/keys/query`\_, passing Bob's user ID in the
|
||||
obtained by calling [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery), passing Bob's user ID in the
|
||||
`device_keys` parameter.
|
||||
|
||||
From time to time, Bob may add new devices, and Alice will need to know
|
||||
this so that she can include his new devices for later encrypted
|
||||
messages. A naive solution to this would be to call `/keys/query`\_
|
||||
messages. A naive solution to this would be to call [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery)
|
||||
before sending each message -however, the number of users and devices
|
||||
may be large and this would be inefficient.
|
||||
|
||||
|
|
@ -157,23 +157,23 @@ process:
|
|||
list, and a separate flag to indicate that its list of Bob's devices
|
||||
is outdated. Both flags should be in storage which persists over
|
||||
client restarts.
|
||||
2. It then makes a request to `/keys/query`\_, passing Bob's user ID in
|
||||
2. It then makes a request to [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery), passing Bob's user ID in
|
||||
the `device_keys` parameter. When the request completes, it stores
|
||||
the resulting list of devices in persistent storage, and clears the
|
||||
'outdated' flag.
|
||||
3. During its normal processing of responses to \_, Alice's client
|
||||
inspects the `changed` property of the `device_lists`\_ field. If it
|
||||
3. During its normal processing of responses to [`/sync`](/client-server-api/#get_matrixclientr0sync), Alice's client
|
||||
inspects the `changed` property of the [`device_lists`](/client-server-api/#extensions-to-sync-1) field. If it
|
||||
is tracking the device lists of any of the listed users, then it
|
||||
marks the device lists for those users outdated, and initiates
|
||||
another request to `/keys/query`\_ for them.
|
||||
another request to [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery) for them.
|
||||
4. Periodically, Alice's client stores the `next_batch` field of the
|
||||
result from \_ in persistent storage. If Alice later restarts her
|
||||
result from [`/sync`](/client-server-api/#get_matrixclientr0sync) in persistent storage. If Alice later restarts her
|
||||
client, it can obtain a list of the users who have updated their
|
||||
device list while it was offline by calling `/keys/changes`\_,
|
||||
device list while it was offline by calling [`/keys/changes`](/client-server-api/#get_matrixclientr0keyschanges),
|
||||
passing the recorded `next_batch` field as the `from` parameter. If
|
||||
the client is tracking the device list of any of the users listed in
|
||||
the response, it marks them as outdated. It combines this list with
|
||||
those already flagged as outdated, and initiates a `/keys/query`\_
|
||||
those already flagged as outdated, and initiates a [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery)
|
||||
request for all of them.
|
||||
|
||||
{{% boxes/warning %}}
|
||||
|
|
@ -342,7 +342,7 @@ Example:
|
|||
|
||||
A client wanting to set up a session with another device can claim a
|
||||
one-time key for that device. This is done by making a request to the
|
||||
`/keys/claim`\_ API.
|
||||
[`/keys/claim`](/client-server-api/#post_matrixclientr0keysclaim) API.
|
||||
|
||||
A homeserver should rate-limit the number of one-time keys that a given
|
||||
user or remote server can claim. A homeserver should discard the public
|
||||
|
|
@ -466,11 +466,11 @@ process.
|
|||
|
||||
After the handshake, the verification process begins.
|
||||
|
||||
{{m\_key\_verification\_request\_event}}
|
||||
{{% event event="m.key.verification.request" %}}
|
||||
|
||||
{{m\_key\_verification\_start\_event}}
|
||||
{{% event event="m.key.verification.start" %}}
|
||||
|
||||
{{m\_key\_verification\_cancel\_event}}
|
||||
{{% event event="m.key.verification.cancel" %}}
|
||||
|
||||
##### Short Authentication String (SAS) verification
|
||||
|
||||
|
|
@ -634,13 +634,13 @@ following error codes are used in addition to those already specified:
|
|||
- `m.mismatched_commitment`: The hash commitment did not match.
|
||||
- `m.mismatched_sas`: The SAS did not match.
|
||||
|
||||
{{m\_key\_verification\_start\_m\_sas\_v1\_event}}
|
||||
{{% event event="m.key.verification.start$m.sas.v1" %}}
|
||||
|
||||
{{m\_key\_verification\_accept\_event}}
|
||||
{{% event event="m.key.verification.accept" %}}
|
||||
|
||||
{{m\_key\_verification\_key\_event}}
|
||||
{{% event event="m.key.verification.key" %}}
|
||||
|
||||
{{m\_key\_verification\_mac\_event}}
|
||||
{{% event event="m.key.verification.mac" %}}
|
||||
|
||||
###### HKDF calculation
|
||||
|
||||
|
|
@ -784,11 +784,11 @@ key, then Alice's device can trust Bob's master key, and she can sign it
|
|||
with her user-signing key.
|
||||
|
||||
Users upload their cross-signing keys to the server using [POST
|
||||
/\_matrix/client/r0/keys/device\_signing/upload](). When Alice uploads
|
||||
/\_matrix/client/r0/keys/device\_signing/upload](/client-server-api/#post_matrixclientr0keysdevice_signingupload). When Alice uploads
|
||||
new cross-signing keys, her user ID will appear in the `changed`
|
||||
property of the `device_lists` field of the `/sync` of response of all
|
||||
users who share an encrypted room with her. When Bob sees Alice's user
|
||||
ID in his `/sync`, he will call [POST /\_matrix/client/r0/keys/query]()
|
||||
ID in his `/sync`, he will call [POST /\_matrix/client/r0/keys/query](/client-server-api/#post_matrixclientr0keysquery)
|
||||
to retrieve Alice's device and cross-signing keys.
|
||||
|
||||
If Alice has a device and wishes to send an encrypted message to Bob,
|
||||
|
|
@ -905,7 +905,7 @@ To avoid leaking of social graphs, servers will only allow users to see:
|
|||
Users will not be able to see signatures made by other users'
|
||||
user-signing keys.
|
||||
|
||||
{{cross\_signing\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="cross_signing" %}}
|
||||
|
||||
#### Sharing keys between devices
|
||||
|
||||
|
|
@ -959,8 +959,8 @@ be encrypted through the backup's `auth_data`; other clients can
|
|||
discover the backup by calling [GET
|
||||
/\_matrix/client/r0/room\_keys/version](#get_matrixclientr0room_keysversion). Keys are encrypted according
|
||||
to the backup's `auth_data` and added to the backup by calling [PUT
|
||||
/\_matrix/client/r0/room\_keys/keys]() or one of its variants, and can
|
||||
be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys](#put_matrixclientr0room_keyskeys) or
|
||||
/\_matrix/client/r0/room\_keys/keys](#put_matrixclientr0room_keyskeys) or one of its variants, and can
|
||||
be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys](#get_matrixclientr0room_keyskeys) or
|
||||
one of its variants. Keys can only be written to the most recently
|
||||
created version of the backup. Backups can also be deleted using [DELETE
|
||||
/\_matrix/client/r0/room\_keys/version/{version}](#delete_matrixclientr0room_keysversionversion), or individual keys
|
||||
|
|
@ -1050,7 +1050,7 @@ The `session_data` field in the backups is constructed as follows:
|
|||
the resulting MAC are base64-encoded, and become the `mac` property
|
||||
of the `session_data`.
|
||||
|
||||
{{key\_backup\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="key_backup" %}}
|
||||
|
||||
##### Key exports
|
||||
|
||||
|
|
@ -1241,7 +1241,7 @@ correspond to the user who sent the event, `recipient` to the local
|
|||
user, and `recipient_keys` to the local ed25519 key.
|
||||
|
||||
Clients must confirm that the `sender_key` and the `ed25519` field value
|
||||
under the `keys` property match the keys returned by `/keys/query`\_ for
|
||||
under the `keys` property match the keys returned by [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery) for
|
||||
the given user, and must also verify the signature of the payload.
|
||||
Without this check, a client cannot be sure that the sender device owns
|
||||
the private part of the ed25519 key it claims to have in the Olm
|
||||
|
|
@ -1355,35 +1355,35 @@ messages.
|
|||
|
||||
##### Events
|
||||
|
||||
{{m\_room\_encryption\_event}}
|
||||
{{% event event="m.room.encryption" %}}
|
||||
|
||||
{{m\_room\_encrypted\_event}}
|
||||
{{% event event="m.room.encrypted" %}}
|
||||
|
||||
{{m\_room\_key\_event}}
|
||||
{{% event event="m.room_key" %}}
|
||||
|
||||
{{m\_room\_key\_request\_event}}
|
||||
{{% event event="m.room_key_request" %}}
|
||||
|
||||
{{m\_forwarded\_room\_key\_event}}
|
||||
{{% event event="m.forwarded_room_key" %}}
|
||||
|
||||
{{m\_dummy\_event}}
|
||||
{{% event event="m.dummy" %}}
|
||||
|
||||
##### Key management API
|
||||
|
||||
{{keys\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="keys" %}}
|
||||
|
||||
##### Extensions to /sync
|
||||
|
||||
This module adds an optional `device_lists` property to the \_ response,
|
||||
This module adds an optional `device_lists` property to the [`/sync`](/client-server-api/#get_matrixclientr0sync) response,
|
||||
as specified below. The server need only populate this property for an
|
||||
incremental `/sync` (i.e., one where the `since` parameter was
|
||||
specified). The client is expected to use `/keys/query`\_ or
|
||||
`/keys/changes`\_ for the equivalent functionality after an initial
|
||||
specified). The client is expected to use [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery) or
|
||||
[`/keys/changes`](/client-server-api/#get_matrixclientr0keyschanges) for the equivalent functionality after an initial
|
||||
sync, as documented in [Tracking the device list for a
|
||||
user](#tracking-the-device-list-for-a-user).
|
||||
|
||||
It also adds a `one_time_keys_count` property. Note the spelling
|
||||
difference with the `one_time_key_counts` property in the
|
||||
`/keys/upload`\_ response.
|
||||
[`/keys/upload`](/client-server-api/#post_matrixclientr0keysupload) response.
|
||||
|
||||
| Parameter | Type | Description |
|
||||
|----------------------------|--------------------|------------------------------------------------------------------------------------------------------------------------|
|
||||
|
|
@ -1451,4 +1451,4 @@ by including a `withheld` property in the `m.forwarded_room_key` message
|
|||
that is an object with the `code` and `reason` properties from the
|
||||
`m.room_key.withheld` message.
|
||||
|
||||
{{m\_room\_key\_withheld\_event}}
|
||||
{{% event event="m.room_key.withheld" %}}
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ an event.
|
|||
There is a single HTTP API for retrieving event context, documented
|
||||
below.
|
||||
|
||||
{{event\_context\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="event_context" %}}
|
||||
|
||||
#### Security considerations
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ rather than allowing all homeservers to enforce the rules on each other.
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_room\_guest\_access\_event}}
|
||||
{{% event event="m.room.guest_access" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ setting at that time was more restrictive.
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_room\_history\_visibility\_event}}
|
||||
{{% event event="m.room.history_visibility" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ and servers can implement the ignoring of users.
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_ignored\_user\_list\_event}}
|
||||
{{% event event="m.ignored_user_list" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
To ignore a user, effectively blocking them, the client should add the
|
||||
target user to the `m.ignored_user_list` event in their account data
|
||||
using \_. Once ignored, the client will no longer receive events sent by
|
||||
using [`/user/<user_id>/account_data/<type>`](/client-server-api/#put_matrixclientr0useruseridaccount_datatype). Once ignored, the client will no longer receive events sent by
|
||||
that user, with the exception of state events. The client should either
|
||||
hide previous content sent by the newly ignored user or perform a new
|
||||
`/sync` with no previous token.
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ room itself such as a room name and topic.
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_room\_message\_event}}
|
||||
{{% event event="m.room.message" %}}
|
||||
|
||||
{{m\_room\_message\_feedback\_event}}
|
||||
{{% event event="m.room.message.feedback" %}}
|
||||
|
||||
Usage of this event is discouraged for several reasons:
|
||||
- The number of feedback events will grow very quickly with the number
|
||||
|
|
@ -24,13 +24,13 @@ Usage of this event is discouraged for several reasons:
|
|||
- There are no guarantees that the client has seen the event ID being
|
||||
acknowledged.
|
||||
|
||||
{{m\_room\_name\_event}}
|
||||
{{% event event="m.room.name" %}}
|
||||
|
||||
{{m\_room\_topic\_event}}
|
||||
{{% event event="m.room.topic" %}}
|
||||
|
||||
{{m\_room\_avatar\_event}}
|
||||
{{% event event="m.room.avatar" %}}
|
||||
|
||||
{{m\_room\_pinned\_events\_event}}
|
||||
{{% event event="m.room.pinned_events" %}}
|
||||
|
||||
##### m.room.message msgtypes
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ extensible message formatting options, such as the proposal
|
|||
[MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767).
|
||||
{{% /boxes/note %}}
|
||||
|
||||
{{msgtype\_events}}
|
||||
{{% msgtypes %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -97,11 +97,11 @@ rules against rooms can describe a room ID or room alias - the
|
|||
subscriber is responsible for resolving the alias to a room ID if
|
||||
desired.
|
||||
|
||||
{{m\_policy\_rule\_user\_event}}
|
||||
{{% event event="m.policy.rule.user" %}}
|
||||
|
||||
{{m\_policy\_rule\_room\_event}}
|
||||
{{% event event="m.policy.rule.room" %}}
|
||||
|
||||
{{m\_policy\_rule\_server\_event}}
|
||||
{{% event event="m.policy.rule.server" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -10,4 +10,4 @@ service. The third party service does need to be matrix-aware in that it
|
|||
will need to know to resolve matrix homeservers to exchange the user's
|
||||
token for identity information.
|
||||
|
||||
{{openid\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="openid" %}}
|
||||
|
|
|
|||
|
|
@ -30,14 +30,14 @@ enum of one of the following:
|
|||
|
||||
#### Events
|
||||
|
||||
{{presence\_events}}
|
||||
{{% event-group group_name="m.presence" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
Clients can manually set/get their presence using the HTTP APIs listed
|
||||
below.
|
||||
|
||||
{{presence\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="presence" %}}
|
||||
|
||||
##### Last active ago
|
||||
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ Clients MUST configure a Pusher before they will receive push
|
|||
notifications. There is a single API endpoint for this, as described
|
||||
below.
|
||||
|
||||
{{pusher\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="pusher" %}}
|
||||
|
||||
##### Listing Notifications
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ A client can retrieve a list of events that it has been notified about.
|
|||
This may be useful so that users can see a summary of what important
|
||||
messages they have received.
|
||||
|
||||
{{notifications\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="notifications" %}}
|
||||
|
||||
##### Receiving notifications
|
||||
|
||||
|
|
@ -658,7 +658,7 @@ Definition:
|
|||
Clients can retrieve, add, modify and remove push rules globally or
|
||||
per-device using the APIs below.
|
||||
|
||||
{{pushrules\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="pushrules" %}}
|
||||
|
||||
##### Push Rules: Events
|
||||
|
||||
|
|
@ -666,7 +666,7 @@ When a user changes their push rules a `m.push_rules` event is sent to
|
|||
all clients in the `account_data` section of their next `/sync` request.
|
||||
The content of the event is the current push rules for the user.
|
||||
|
||||
{{m\_push\_rules\_event}}
|
||||
{{% event event="m.push_rules" %}}
|
||||
|
||||
###### Examples
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ The fully read marker is kept under an `m.fully_read` event. If the
|
|||
event does not exist on the user's account data, the fully read marker
|
||||
should be considered to be the user's read receipt location.
|
||||
|
||||
{{m\_fully\_read\_event}}
|
||||
{{% event event="m.fully_read" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ commonly updated at the same time, and therefore the client might wish
|
|||
to save an extra HTTP call. Providing an `m.read` location performs the
|
||||
same task as a request to `/receipt/m.read/$event:example.org`.
|
||||
|
||||
{{read\_markers\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="read_markers" %}}
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ information on how read receipts affect notification counts.
|
|||
Each `user_id`, `receipt_type` pair must be associated with only a
|
||||
single `event_id`.
|
||||
|
||||
{{m\_receipt\_event}}
|
||||
{{% event event="m.receipt" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ for events sent by their own user.
|
|||
A client can update the markers for its user by interacting with the
|
||||
following HTTP APIs.
|
||||
|
||||
{{receipts\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="receipts" %}}
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ offensive" and 0 is "inoffensive".
|
|||
|
||||
#### Client behaviour
|
||||
|
||||
{{report\_content\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="report_content" %}}
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Clients can of course also call other endpoints such as [GET
|
|||
and [GET /search](#post_matrixclientr0search) to
|
||||
access events outside the `/events` stream.
|
||||
|
||||
{{peeking\_events\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="peeking_events" %}}
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ to upgrade to a different room version when needed.
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_room\_tombstone\_event}}
|
||||
{{% event event="m.room.tombstone" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ old room. Another approach may be to virtually merge the rooms such that
|
|||
the old room's timeline seamlessly continues into the new timeline
|
||||
without the user having to jump between the rooms.
|
||||
|
||||
{{room\_upgrades\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="room_upgrades" %}}
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ it won't include events in rooms that happened after you left.
|
|||
There is a single HTTP API for performing server-side search, documented
|
||||
below.
|
||||
|
||||
{{search\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="search" %}}
|
||||
|
||||
#### Search Categories
|
||||
|
||||
|
|
|
|||
|
|
@ -13,26 +13,27 @@ client device.
|
|||
The primary motivation for this API is exchanging data that is
|
||||
meaningless or undesirable to persist in the room DAG - for example,
|
||||
one-time authentication tokens or key data. It is not intended for
|
||||
conversational data, which should be sent using the normal \_ API for
|
||||
conversational data, which should be sent using the normal [`/rooms/<room_id>/send`](/client-server-api/#put_matrixclientr0roomsroomidsendeventtypetxnid) API for
|
||||
consistency throughout Matrix.
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
To send a message to other devices, a client should call
|
||||
`/sendToDevice`\_. Only one message can be sent to each device per
|
||||
[`/sendToDevice`](/client-server-api/#put_matrixclientr0sendtodeviceeventtypetxnid). Only one message can be sent to each device per
|
||||
transaction, and they must all have the same event type. The device ID
|
||||
in the request body can be set to `*` to request that the message be
|
||||
sent to all known devices.
|
||||
|
||||
If there are send-to-device messages waiting for a client, they will be
|
||||
returned by \_, as detailed in Extensions to /sync\_. Clients should
|
||||
returned by [`/sync`](/client-server-api/#get_matrixclientr0sync), as detailed in [Extensions to /sync](/client-server-api/#extensions-to-sync). Clients should
|
||||
inspect the `type` of each returned event, and ignore any they do not
|
||||
understand.
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
Servers should store pending messages for local users until they are
|
||||
successfully delivered to the destination device. When a client calls \_
|
||||
successfully delivered to the destination device. When a client calls
|
||||
[`/sync`](/client-server-api/#get_matrixclientr0sync)
|
||||
with an access token which corresponds to a device with pending
|
||||
messages, the server should list the pending messages, in order of
|
||||
arrival, in the response body.
|
||||
|
|
@ -52,11 +53,11 @@ should be sent on to the remote servers via
|
|||
|
||||
#### Protocol definitions
|
||||
|
||||
{{to\_device\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="to_device" %}}
|
||||
|
||||
##### Extensions to /sync
|
||||
|
||||
This module adds the following properties to the \_ response:
|
||||
This module adds the following properties to the [`/sync`](/client-server-api/#get_matrixclientr0sync) response:
|
||||
|
||||
| Parameter | Type | Description |
|
||||
|-----------|-----------|-----------------------------------------------------------------------------|
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ set of servers, or retroactively make the room no longer federate with
|
|||
any other server, similar to setting the `m.federate` value on the
|
||||
[m.room.create](#mroomcreate) event.
|
||||
|
||||
{{m\_room\_server\_acl\_event}}
|
||||
{{% event event="m.room.server_acl" %}}
|
||||
|
||||
{{% boxes/note %}}
|
||||
Port numbers are not supported because it is unclear to parsers whether
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ maximum. New connections are being refused by the server. What defines
|
|||
"active" is left as an implementation detail, however servers are
|
||||
encouraged to treat syncing users as "active".
|
||||
|
||||
{{m\_room\_message\_m\_server\_notice\_event}}
|
||||
{{% event event="m.room.message$m.server_notice" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -43,12 +43,12 @@ endpoints which consume the ticket.
|
|||
|
||||
An overview of the process is as follows:
|
||||
|
||||
1. The Matrix client calls `GET /login`\_ to find the supported login
|
||||
1. The Matrix client calls [`GET /login`](/client-server-api/#get_matrixclientr0login) to find the supported login
|
||||
types, and the homeserver includes a flow with
|
||||
`"type": "m.login.sso"` in the response.
|
||||
2. To initiate the `m.login.sso` login type, the Matrix client
|
||||
instructs the user's browser to navigate to the
|
||||
`/login/sso/redirect`\_ endpoint on the user's homeserver.
|
||||
[`/login/sso/redirect`](/client-server-api/#get_matrixclientr0loginssoredirect) endpoint on the user's homeserver.
|
||||
3. The homeserver responds with an HTTP redirect to the SSO user
|
||||
interface, which the browser follows.
|
||||
4. The authentication server and the homeserver interact to verify the
|
||||
|
|
@ -57,7 +57,7 @@ An overview of the process is as follows:
|
|||
5. The browser is directed to the `redirectUrl` provided by the client
|
||||
with a `loginToken` query parameter for the client to log in with.
|
||||
6. The client exchanges the login token for an access token by calling
|
||||
the `/login`\_ endpoint with a `type` of `m.login.token`.
|
||||
the [`/login`](/client-server-api/#post_matrixclientr0login) endpoint with a `type` of `m.login.token`.
|
||||
|
||||
For native applications, typically steps 1 to 4 are carried out by
|
||||
opening an embedded web view.
|
||||
|
|
@ -100,11 +100,11 @@ otherwise the same.
|
|||
##### Client behaviour
|
||||
|
||||
The client starts the process by instructing the browser to navigate to
|
||||
`/login/sso/redirect`\_ with an appropriate `redirectUrl`. Once
|
||||
[`/login/sso/redirect`](/client-server-api/#get_matrixclientr0loginssoredirect) with an appropriate `redirectUrl`. Once
|
||||
authentication is successful, the browser will be redirected to that
|
||||
`redirectUrl`.
|
||||
|
||||
{{sso\_login\_redirect\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="sso_login_redirect" %}}
|
||||
|
||||
###### Security considerations
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ The homeserver then proceeds as follows:
|
|||
registered as a new user.
|
||||
3. The homeserver should generate a short-term login token. This is an
|
||||
opaque token, suitable for use with the `m.login.token` type of the
|
||||
`/login`\_ API. The lifetime of this token SHOULD be limited to
|
||||
[`/login`](/client-server-api/#post_matrixclientr0login) API. The lifetime of this token SHOULD be limited to
|
||||
around five seconds.
|
||||
4. The homeserver adds a query parameter of `loginToken`, with the
|
||||
value of the generated login token, to the `redirectUrl` given in
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ when the sticker image is clicked.
|
|||
Sticker events are received as a single `m.sticker` event in the
|
||||
`timeline` section of a room, in a `/sync`.
|
||||
|
||||
{{m\_sticker\_event}}
|
||||
{{% event event="m.sticker" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -59,8 +59,8 @@ tags are defined in the `m.*` namespace:
|
|||
- `m.server_notice`: Used to identify [Server Notice
|
||||
Rooms](#server-notices).
|
||||
|
||||
{{m\_tag\_event}}
|
||||
{{% event event="m.tag" %}}
|
||||
|
||||
#### Client Behaviour
|
||||
|
||||
{{tags\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="tags" %}}
|
||||
|
|
|
|||
|
|
@ -31,13 +31,13 @@ invitee does indeed own that third party identifier. See the
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_room\_third\_party\_invite\_event}}
|
||||
{{% event event="m.room.third_party_invite" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
A client asks a server to invite a user by their third party identifier.
|
||||
|
||||
{{third\_party\_membership\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="third_party_membership" %}}
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
|
|
|
|||
|
|
@ -19,4 +19,4 @@ A client may wish to provide a rich interface for joining third party
|
|||
locations and connecting with third party users. Information necessary
|
||||
for such an interface is provided by third party lookups.
|
||||
|
||||
{{third\_party\_lookup\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="third_party_lookup" %}}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ events scoped to a `room_id`. This means they do not form part of the
|
|||
|
||||
#### Events
|
||||
|
||||
{{m\_typing\_event}}
|
||||
{{% event event="m.typing" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ recommended. When the user stops typing, the state change of the
|
|||
`boolean` to `false` should trigger another HTTP request to inform the
|
||||
server that the user has stopped typing.
|
||||
|
||||
{{typing\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="typing" %}}
|
||||
|
||||
#### Security considerations
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ send call events to rooms with exactly two participants.
|
|||
|
||||
#### Events
|
||||
|
||||
{{voip\_events}}
|
||||
{{% event-group group_name="m.call" %}}
|
||||
|
||||
#### Client behaviour
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ The homeserver MAY provide a TURN server which clients can use to
|
|||
contact the remote party. The following HTTP API endpoints will be used
|
||||
by clients in order to get information about the TURN server.
|
||||
|
||||
{{voip\_cs\_http\_api}}
|
||||
{{% http-api spec="client-server" api="voip" %}}
|
||||
|
||||
#### Security considerations
|
||||
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ header is inaccessible for the client.
|
|||
When credentials are required but missing or invalid, the HTTP call will
|
||||
return with a status of 401 and the error code `M_UNAUTHORIZED`.
|
||||
|
||||
{{v2\_auth\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_auth" %}}
|
||||
|
||||
## Terms of service
|
||||
|
||||
|
|
@ -196,15 +196,15 @@ the client should not expect that the server will not respond with
|
|||
another `M_TERMS_NOT_SIGNED` on their next request. The terms the user
|
||||
has just accepted are appended to `m.accepted_terms`.
|
||||
|
||||
{{m\_accepted\_terms\_event}}
|
||||
{{% event event="m.accepted_terms" %}}
|
||||
|
||||
{{v2\_terms\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_terms" %}}
|
||||
|
||||
## Status check
|
||||
|
||||
{{ping\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="ping" %}}
|
||||
|
||||
{{v2\_ping\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_ping" %}}
|
||||
|
||||
## Key management
|
||||
|
||||
|
|
@ -217,15 +217,15 @@ The identity server may also keep track of some short-term
|
|||
public-private keypairs, which may have different usage and lifetime
|
||||
characteristics than the service's long-term keys.
|
||||
|
||||
{{pubkey\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="pubkey" %}}
|
||||
|
||||
{{v2\_pubkey\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_pubkey" %}}
|
||||
|
||||
## Association lookup
|
||||
|
||||
{{lookup\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="lookup" %}}
|
||||
|
||||
{{v2\_lookup\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_lookup" %}}
|
||||
|
||||
### Client behaviour
|
||||
|
||||
|
|
@ -398,21 +398,21 @@ through without modification.
|
|||
|
||||
### Email associations
|
||||
|
||||
{{email\_associations\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="email_associations" %}}
|
||||
|
||||
{{v2\_email\_associations\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_email_associations" %}}
|
||||
|
||||
### Phone number associations
|
||||
|
||||
{{phone\_associations\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="phone_associations" %}}
|
||||
|
||||
{{v2\_phone\_associations\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_phone_associations" %}}
|
||||
|
||||
### General
|
||||
|
||||
{{associations\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="associations" %}}
|
||||
|
||||
{{v2\_associations\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_associations" %}}
|
||||
|
||||
## Invitation storage
|
||||
|
||||
|
|
@ -427,9 +427,9 @@ the Matrix user's homeserver via the
|
|||
endpoint. The request MUST be signed with a long-term private key for
|
||||
the identity server.
|
||||
|
||||
{{store\_invite\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="store_invite" %}}
|
||||
|
||||
{{v2\_store\_invite\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_store_invite" %}}
|
||||
|
||||
## Ephemeral invitation signing
|
||||
|
||||
|
|
@ -438,6 +438,6 @@ identity server offers some crypto functionality to help in accepting
|
|||
invitations. This is less secure than the client doing it itself, but
|
||||
may be useful where this isn't possible.
|
||||
|
||||
{{invitation\_signing\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="invitation_signing" %}}
|
||||
|
||||
{{v2\_invitation\_signing\_is\_http\_api}}
|
||||
{{% http-api spec="identity" api="v2_invitation_signing" %}}
|
||||
|
|
|
|||
|
|
@ -54,4 +54,4 @@ Note that most of the values and behaviour of this endpoint is described
|
|||
by the Client-Server API's [Push
|
||||
Module](/client-server-api#push-notifications).
|
||||
|
||||
{{push\_notifier\_push\_http\_api}}
|
||||
{{% http-api spec="push-gateway" api="push_notifier" %}}
|
||||
|
|
|
|||
|
|
@ -276,7 +276,7 @@ Some consequences of these rules:
|
|||
|
||||
Events in version 1 rooms have the following structure:
|
||||
|
||||
{{definition\_ss\_pdu}}
|
||||
{{% definition path="api/server-server/definitions/pdu" %}}
|
||||
|
||||
### Canonical JSON
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ Additionally, the `auth_events` and `prev_events` have had a format
|
|||
change compared to other room versions to make it easier to handle.
|
||||
Instead of a tuple of values, they are now plain lists of events.
|
||||
|
||||
{{definition\_ss\_pdu\_v3}}
|
||||
{{% definition path="api/server-server/definitions/pdu_v3" %}}
|
||||
|
||||
### Changes to APIs
|
||||
|
||||
|
|
|
|||
|
|
@ -58,4 +58,4 @@ receiving end of an event, the server should compute the relevant event
|
|||
ID for itself. Room version 3 also changes the format of `auth_events`
|
||||
and `prev_events` in a PDU.
|
||||
|
||||
{{definition\_ss\_pdu\_v4}}
|
||||
{{% definition path="api/server-server/definitions/pdu_v4" %}}
|
||||
|
|
|
|||
|
|
@ -150,11 +150,11 @@ SNI is not supported and should not be sent.
|
|||
Servers are encouraged to make use of the [Certificate
|
||||
Transparency](https://www.certificate-transparency.org/) project.
|
||||
|
||||
{{wellknown\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="wellknown" %}}
|
||||
|
||||
### Server implementation
|
||||
|
||||
{{version\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="version" %}}
|
||||
|
||||
### Retrieving server keys
|
||||
|
||||
|
|
@ -190,7 +190,7 @@ Homeservers publish their signing keys in a JSON object at
|
|||
homeserver and for signing events. It contains a list of
|
||||
`old_verify_keys` which are only valid for signing events.
|
||||
|
||||
{{keys\_server\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="keys_server" %}}
|
||||
|
||||
#### Querying Keys Through Another Server
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ Notary servers can return keys for servers that are offline or having
|
|||
issues serving their own keys by using cached responses. Keys can be
|
||||
queried from multiple servers to mitigate against DNS spoofing.
|
||||
|
||||
{{keys\_query\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="keys_query" %}}
|
||||
|
||||
## Authentication
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ pair of homeservers that exchanged it; they are not globally-meaningful.
|
|||
Transactions are limited in size; they can have at most 50 PDUs and 100
|
||||
EDUs.
|
||||
|
||||
{{transactions\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="transactions" %}}
|
||||
|
||||
## PDUs
|
||||
|
||||
|
|
@ -559,7 +559,7 @@ to check with other servers to ensure it is receiving the correct auth
|
|||
chain. These APIs give the homeserver an avenue for getting the
|
||||
information it needs.
|
||||
|
||||
{{event\_auth\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="event_auth" %}}
|
||||
|
||||
## EDUs
|
||||
|
||||
|
|
@ -567,7 +567,7 @@ EDUs, by comparison to PDUs, do not have an ID, a room ID, or a list of
|
|||
"previous" IDs. They are intended to be non-persistent data such as user
|
||||
presence, typing notifications, etc.
|
||||
|
||||
{{definition\_ss\_edu}}
|
||||
{{% definition path="api/server-server/definitions/edu" %}}
|
||||
|
||||
## Room State Resolution
|
||||
|
||||
|
|
@ -623,7 +623,7 @@ Similar to backfilling a room's history, a server may not have all the
|
|||
events in the graph. That server may use the `/get_missing_events` API
|
||||
to acquire the events it is missing.
|
||||
|
||||
{{backfill\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="backfill" %}}
|
||||
|
||||
## Retrieving events
|
||||
|
||||
|
|
@ -632,7 +632,7 @@ information about the room which cannot be easily determined from
|
|||
backfilling. These APIs provide homeservers with the option of getting
|
||||
events and the state of the room at a given point in the timeline.
|
||||
|
||||
{{events\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="events" %}}
|
||||
|
||||
## Joining Rooms
|
||||
|
||||
|
|
@ -688,7 +688,7 @@ in practice will use just two.
|
|||
|
||||
The first part of the handshake usually involves using the directory
|
||||
server to request the room ID and join candidates through the
|
||||
`/query/directory`\_ API endpoint. In the case of a new user joining a
|
||||
[`/query/directory`](/server-server-api/#get_matrixfederationv1querydirectory) API endpoint. In the case of a new user joining a
|
||||
room as a result of a received invite, the joining user's homeserver
|
||||
could optimise this step away by picking the origin server of that
|
||||
invite message as the join candidate. However, the joining server should
|
||||
|
|
@ -716,9 +716,9 @@ graph, and responds to the joining server with the full set of state for
|
|||
the newly-joined room. The resident server must also send the event to
|
||||
other servers participating in the room.
|
||||
|
||||
{{joins\_v1\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="joins-v1" %}}
|
||||
|
||||
{{joins\_v2\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="joins-v2" %}}
|
||||
|
||||
## Inviting to a room
|
||||
|
||||
|
|
@ -728,9 +728,9 @@ the process defined here. However, when a user invites another user on a
|
|||
different homeserver, a request to that homeserver to have the event
|
||||
signed and verified must be made.
|
||||
|
||||
{{invites\_v1\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="invites-v1" %}}
|
||||
|
||||
{{invites\_v2\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="invites-v2" %}}
|
||||
|
||||
## Leaving Rooms (Rejecting Invites)
|
||||
|
||||
|
|
@ -751,9 +751,9 @@ and replaces the `event_id` with its own. This is then sent to the
|
|||
resident server via `/send_leave`. The resident server will then send
|
||||
the event to other servers in the room.
|
||||
|
||||
{{leaving\_v1\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="leaving-v1" %}}
|
||||
|
||||
{{leaving\_v2\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="leaving-v2" %}}
|
||||
|
||||
## Third-party invites
|
||||
|
||||
|
|
@ -806,7 +806,7 @@ auth the event and send it.
|
|||
However, if the invited homeserver isn't in the room the invite came
|
||||
from, it will need to request the room's homeserver to auth the event.
|
||||
|
||||
{{third\_party\_invite\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="third_party_invite" %}}
|
||||
|
||||
#### Verifying the invite
|
||||
|
||||
|
|
@ -841,7 +841,7 @@ homeservers need a way to query the public rooms for another server.
|
|||
This can be done by making a request to the `/publicRooms` endpoint for
|
||||
the server the room directory should be retrieved for.
|
||||
|
||||
{{public\_rooms\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="public_rooms" %}}
|
||||
|
||||
## Typing Notifications
|
||||
|
||||
|
|
@ -850,7 +850,7 @@ need to be sent to other servers in the room so their users are aware of
|
|||
the same state. Receiving servers should verify that the user is in the
|
||||
room, and is a user belonging to the sending server.
|
||||
|
||||
{{definition\_ss\_event\_schemas\_m\_typing}}
|
||||
{{% definition path="api/server-server/definitions/event-schemas/m.typing" %}}
|
||||
|
||||
## Presence
|
||||
|
||||
|
|
@ -861,7 +861,7 @@ Servers should only send presence updates for users that the receiving
|
|||
server would be interested in. Such as the receiving server sharing a
|
||||
room with a given user.
|
||||
|
||||
{{definition\_ss\_event\_schemas\_m\_presence}}
|
||||
{{% definition path="api/server-server/definitions/event-schemas/m.presence" %}}
|
||||
|
||||
## Receipts
|
||||
|
||||
|
|
@ -872,7 +872,7 @@ where in the event graph the user has read up to.
|
|||
Read receipts for events that a user sent do not need to be sent. It is
|
||||
implied that by sending the event the user has read up to the event.
|
||||
|
||||
{{definition\_ss\_event\_schemas\_m\_receipt}}
|
||||
{{% definition path="api/server-server/definitions/event-schemas/m.receipt" %}}
|
||||
|
||||
## Querying for information
|
||||
|
||||
|
|
@ -885,7 +885,7 @@ There are several types of queries that can be made. The generic
|
|||
endpoint to represent all queries is described first, followed by the
|
||||
more specific queries that can be made.
|
||||
|
||||
{{query\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="query" %}}
|
||||
|
||||
## OpenID
|
||||
|
||||
|
|
@ -897,7 +897,7 @@ without granting full access to the user's account.
|
|||
Access tokens generated by the OpenID API are only good for the OpenID
|
||||
API and nothing else.
|
||||
|
||||
{{openid\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="openid" %}}
|
||||
|
||||
## Device Management
|
||||
|
||||
|
|
@ -943,9 +943,9 @@ recognise, it must resynchronise its list by calling the
|
|||
`stream_id` which should be used to correlate with subsequent
|
||||
`m.device_list_update` EDUs.
|
||||
|
||||
{{user\_devices\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="user_devices" %}}
|
||||
|
||||
{{definition\_ss\_event\_schemas\_m\_device\_list\_update}}
|
||||
{{% definition path="api/server-server/definitions/event-schemas/m.device_list_update" %}}
|
||||
|
||||
## End-to-End Encryption
|
||||
|
||||
|
|
@ -958,9 +958,9 @@ The APIs defined here are designed to be able to proxy much of the
|
|||
client's request through to federation, and have the response also be
|
||||
proxied through to the client.
|
||||
|
||||
{{user\_keys\_ss\_http\_api}}
|
||||
{{% http-api spec="server-server" api="user_keys" %}}
|
||||
|
||||
{{definition\_ss\_event\_schemas\_m\_signing\_key\_update}}
|
||||
{{% definition path="api/server-server/definitions/event-schemas/m.signing_key_update" %}}
|
||||
|
||||
## Send-to-device messaging
|
||||
|
||||
|
|
@ -971,7 +971,7 @@ involved.
|
|||
Each send-to-device message should be sent to the destination server
|
||||
using the following EDU:
|
||||
|
||||
{{definition\_ss\_event\_schemas\_m\_direct\_to\_device}}
|
||||
{{% definition path="api/server-server/definitions/event-schemas/m.direct_to_device" %}}
|
||||
|
||||
## Content Repository
|
||||
|
||||
|
|
|
|||
|
|
@ -43,9 +43,9 @@ properties:
|
|||
field_types:
|
||||
title: Field Types
|
||||
description: |-
|
||||
The type definitions for the fields defined in the ``user_fields`` and
|
||||
``location_fields``. Each entry in those arrays MUST have an entry here. The
|
||||
``string`` key for this object is field name itself.
|
||||
The type definitions for the fields defined in the `user_fields` and
|
||||
`location_fields`. Each entry in those arrays MUST have an entry here. The
|
||||
`string` key for this object is field name itself.
|
||||
|
||||
May be an empty object if no fields are defined.
|
||||
type: object
|
||||
|
|
@ -101,7 +101,7 @@ properties:
|
|||
example: "mxc://example.org/JkLmNoPq"
|
||||
fields:
|
||||
type: object
|
||||
description: Preset values for ``fields`` the client may use to search by.
|
||||
description: Preset values for `fields` the client may use to search by.
|
||||
example: {
|
||||
"network": "freenode"
|
||||
}
|
||||
|
|
@ -13,6 +13,6 @@
|
|||
# limitations under the License.
|
||||
homeserverAccessToken:
|
||||
type: apiKey
|
||||
description: The ``hs_token`` provided by the application service's registration.
|
||||
description: The `hs_token` provided by the application service's registration.
|
||||
name: access_token
|
||||
in: query
|
||||
|
|
@ -34,7 +34,7 @@ paths:
|
|||
description: |-
|
||||
This endpoint is invoked by the homeserver on an application service to query
|
||||
the existence of a given room alias. The homeserver will only query room
|
||||
aliases inside the application service's ``aliases`` namespace. The
|
||||
aliases inside the application service's `aliases` namespace. The
|
||||
homeserver will send this request when it receives a request to join a
|
||||
room alias within the application service's namespace.
|
||||
operationId: queryRoomByAlias
|
||||
|
|
@ -34,7 +34,7 @@ paths:
|
|||
description: |-
|
||||
This endpoint is invoked by the homeserver on an application service to query
|
||||
the existence of a given user ID. The homeserver will only query user IDs
|
||||
inside the application service's ``users`` namespace. The homeserver will
|
||||
inside the application service's `users` namespace. The homeserver will
|
||||
send this request when it receives an event for an unknown user ID in
|
||||
the application service's namespace, such as a room invite.
|
||||
operationId: queryUserById
|
||||
|
|
@ -34,7 +34,7 @@ paths:
|
|||
(or batch of events) to the application service.
|
||||
|
||||
Note that the application service should distinguish state events
|
||||
from message events via the presence of a ``state_key``, rather than
|
||||
from message events via the presence of a `state_key`, rather than
|
||||
via the event type.
|
||||
operationId: sendTransaction
|
||||
security:
|
||||
|
|
@ -55,8 +55,8 @@ paths:
|
|||
type: object
|
||||
example: {
|
||||
"events": [
|
||||
{"$ref": "../../event-schemas/examples/m.room.member"},
|
||||
{"$ref": "../../event-schemas/examples/m.room.message$m.text"}
|
||||
{"$ref": "../../event-schemas/examples/m.room.member.yaml"},
|
||||
{"$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"}
|
||||
]
|
||||
}
|
||||
properties:
|
||||
|
|
@ -33,7 +33,7 @@ paths:
|
|||
description: |-
|
||||
Set some account_data for the client. This config is only visible to the user
|
||||
that set the account_data. The config will be synced to clients in the
|
||||
top-level ``account_data``.
|
||||
top-level `account_data`.
|
||||
operationId: setAccountData
|
||||
security:
|
||||
- accessToken: []
|
||||
|
|
@ -110,7 +110,7 @@ paths:
|
|||
description: |-
|
||||
Set some account_data for the client on a given room. This config is only
|
||||
visible to the user that set the account_data. The config will be synced to
|
||||
clients in the per-room ``account_data``.
|
||||
clients in the per-room `account_data`.
|
||||
operationId: setAccountDataPerRoom
|
||||
security:
|
||||
- accessToken: []
|
||||
|
|
@ -93,14 +93,14 @@ paths:
|
|||
description: |-
|
||||
Adds contact information to the user's account.
|
||||
|
||||
This endpoint is deprecated in favour of the more specific ``/3pid/add``
|
||||
and ``/3pid/bind`` endpoints.
|
||||
This endpoint is deprecated in favour of the more specific `/3pid/add`
|
||||
and `/3pid/bind` endpoints.
|
||||
|
||||
.. Note::
|
||||
Previously this endpoint supported a ``bind`` parameter. This parameter
|
||||
has been removed, making this endpoint behave as though it was ``false``.
|
||||
This results in this endpoint being an equivalent to ``/3pid/bind`` rather
|
||||
than dual-purpose.
|
||||
**Note:**
|
||||
Previously this endpoint supported a `bind` parameter. This parameter
|
||||
has been removed, making this endpoint behave as though it was `false`.
|
||||
This results in this endpoint being an equivalent to `/3pid/bind` rather
|
||||
than dual-purpose.
|
||||
operationId: post3PIDs
|
||||
deprecated: true
|
||||
security:
|
||||
|
|
@ -157,8 +157,8 @@ paths:
|
|||
description: |-
|
||||
An optional field containing a URL where the client must
|
||||
submit the validation token to, with identical parameters
|
||||
to the Identity Service API's ``POST
|
||||
/validate/email/submitToken`` endpoint (without the requirement
|
||||
to the Identity Service API's `POST
|
||||
/validate/email/submitToken` endpoint (without the requirement
|
||||
for an access token). The homeserver must send this token to the
|
||||
user (if applicable), who should then be prompted to provide it
|
||||
to the client.
|
||||
|
|
@ -166,7 +166,7 @@ paths:
|
|||
If this field is not present, the client can assume that
|
||||
verification will happen without the client's involvement
|
||||
provided the homeserver advertises this specification version
|
||||
in the ``/versions`` response (ie: r0.5.0).
|
||||
in the `/versions` response (ie: r0.5.0).
|
||||
example: "https://example.org/path/to/submitToken"
|
||||
403:
|
||||
description: The credentials could not be verified with the identity server.
|
||||
|
|
@ -183,7 +183,7 @@ paths:
|
|||
post:
|
||||
summary: Adds contact information to the user's account.
|
||||
description: |-
|
||||
This API endpoint uses the `User-Interactive Authentication API`_.
|
||||
This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
|
||||
|
||||
Adds contact information to the user's account. Homeservers should use 3PIDs added
|
||||
through this endpoint for password resets instead of relying on the identity server.
|
||||
|
|
@ -294,7 +294,7 @@ paths:
|
|||
Removes a third party identifier from the user's account. This might not
|
||||
cause an unbind of the identifier from the identity server.
|
||||
|
||||
Unlike other endpoints, this endpoint does not take an ``id_access_token``
|
||||
Unlike other endpoints, this endpoint does not take an `id_access_token`
|
||||
parameter because the homeserver is expected to sign the request to the
|
||||
identity server instead.
|
||||
operationId: delete3pidFromAccount
|
||||
|
|
@ -311,9 +311,9 @@ paths:
|
|||
type: string
|
||||
description: |-
|
||||
The identity server to unbind from. If not provided, the homeserver
|
||||
MUST use the ``id_server`` the identifier was added through. If the
|
||||
homeserver does not know the original ``id_server``, it MUST return
|
||||
a ``id_server_unbind_result`` of ``no-support``.
|
||||
MUST use the `id_server` the identifier was added through. If the
|
||||
homeserver does not know the original `id_server`, it MUST return
|
||||
a `id_server_unbind_result` of `no-support`.
|
||||
example: "example.org"
|
||||
medium:
|
||||
type: string
|
||||
|
|
@ -342,8 +342,8 @@ paths:
|
|||
- "success"
|
||||
description: |-
|
||||
An indicator as to whether or not the homeserver was able to unbind
|
||||
the 3PID from the identity server. ``success`` indicates that the
|
||||
indentity server has unbound the identifier whereas ``no-support``
|
||||
the 3PID from the identity server. `success` indicates that the
|
||||
indentity server has unbound the identifier whereas `no-support`
|
||||
indicates that the identity server refuses to support the request
|
||||
or the homeserver was not able to determine an identity server to
|
||||
unbind from.
|
||||
|
|
@ -359,7 +359,7 @@ paths:
|
|||
Removes a user's third party identifier from the provided identity server
|
||||
without removing it from the homeserver.
|
||||
|
||||
Unlike other endpoints, this endpoint does not take an ``id_access_token``
|
||||
Unlike other endpoints, this endpoint does not take an `id_access_token`
|
||||
parameter because the homeserver is expected to sign the request to the
|
||||
identity server instead.
|
||||
operationId: unbind3pidFromAccount
|
||||
|
|
@ -376,9 +376,9 @@ paths:
|
|||
type: string
|
||||
description: |-
|
||||
The identity server to unbind from. If not provided, the homeserver
|
||||
MUST use the ``id_server`` the identifier was added through. If the
|
||||
homeserver does not know the original ``id_server``, it MUST return
|
||||
a ``id_server_unbind_result`` of ``no-support``.
|
||||
MUST use the `id_server` the identifier was added through. If the
|
||||
homeserver does not know the original `id_server`, it MUST return
|
||||
a `id_server_unbind_result` of `no-support`.
|
||||
example: "example.org"
|
||||
medium:
|
||||
type: string
|
||||
|
|
@ -407,8 +407,8 @@ paths:
|
|||
- "success"
|
||||
description: |-
|
||||
An indicator as to whether or not the identity server was able to unbind
|
||||
the 3PID. ``success`` indicates that the identity server has unbound the
|
||||
identifier whereas ``no-support`` indicates that the identity server
|
||||
the 3PID. `success` indicates that the identity server has unbound the
|
||||
identifier whereas `no-support` indicates that the identity server
|
||||
refuses to support the request or the homeserver was not able to determine
|
||||
an identity server to unbind from.
|
||||
example: "success"
|
||||
|
|
@ -424,7 +424,8 @@ paths:
|
|||
already associated with an account on this homeserver. This API should
|
||||
be used to request validation tokens when adding an email address to an
|
||||
account. This API's parameters and response are identical to that of
|
||||
the |/register/email/requestToken|_ endpoint. The homeserver should validate
|
||||
the [`/register/email/requestToken`](/client-server-api/#post_matrixclientr0registeremailrequesttoken)
|
||||
endpoint. The homeserver should validate
|
||||
the email itself, either by sending a validation email itself or by using
|
||||
a service it has control over.
|
||||
operationId: requestTokenTo3PIDEmail
|
||||
|
|
@ -456,7 +457,7 @@ paths:
|
|||
400:
|
||||
description: |-
|
||||
The third party identifier is already in use on the homeserver, or
|
||||
the request was invalid. The error code ``M_SERVER_NOT_TRUSTED``
|
||||
the request was invalid. The error code `M_SERVER_NOT_TRUSTED`
|
||||
can be returned if the server does not trust/support the identity server
|
||||
provided in the request.
|
||||
schema:
|
||||
|
|
@ -474,7 +475,8 @@ paths:
|
|||
already associated with an account on this homeserver. This API should
|
||||
be used to request validation tokens when adding a phone number to an
|
||||
account. This API's parameters and response are identical to that of
|
||||
the |/register/msisdn/requestToken|_ endpoint. The homeserver should validate
|
||||
the [`/register/msisdn/requestToken`](/client-server-api/#post_matrixclientr0registermsisdnrequesttoken)
|
||||
endpoint. The homeserver should validate
|
||||
the phone number itself, either by sending a validation message itself or by using
|
||||
a service it has control over.
|
||||
operationId: requestTokenTo3PIDMSISDN
|
||||
|
|
@ -503,7 +505,7 @@ paths:
|
|||
400:
|
||||
description: |-
|
||||
The third party identifier is already in use on the homeserver, or
|
||||
the request was invalid. The error code ``M_SERVER_NOT_TRUSTED``
|
||||
the request was invalid. The error code `M_SERVER_NOT_TRUSTED`
|
||||
can be returned if the server does not trust/support the identity server
|
||||
provided in the request.
|
||||
schema:
|
||||
|
|
@ -40,7 +40,7 @@ paths:
|
|||
This API is similar to the room directory visibility API used by clients
|
||||
to update the homeserver's more general room directory.
|
||||
|
||||
This API requires the use of an application service access token (``as_token``)
|
||||
This API requires the use of an application service access token (`as_token`)
|
||||
instead of a typical client's access_token. This API cannot be invoked by
|
||||
users who are not identified as application services.
|
||||
operationId: updateAppserviceRoomDirectoryVsibility
|
||||
|
|
@ -62,7 +62,7 @@ paths:
|
|||
reason:
|
||||
type: string
|
||||
description: The reason the user has been banned. This will be supplied as the
|
||||
``reason`` on the target's updated `m.room.member`_ event.
|
||||
`reason` on the target's updated [`m.room.member`](/client-server-api/#mroommember) event.
|
||||
required: ["user_id"]
|
||||
responses:
|
||||
200:
|
||||
|
|
@ -74,7 +74,7 @@ paths:
|
|||
type: object
|
||||
403:
|
||||
description: |-
|
||||
You do not have permission to ban the user from the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
|
||||
You do not have permission to ban the user from the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are:
|
||||
|
||||
- The banner is not currently in the room.
|
||||
- The banner's power level is insufficient to ban users from the room.
|
||||
|
|
@ -121,7 +121,7 @@ paths:
|
|||
reason:
|
||||
type: string
|
||||
description: |-
|
||||
Optional reason to be included as the ``reason`` on the subsequent
|
||||
Optional reason to be included as the `reason` on the subsequent
|
||||
membership event.
|
||||
required: ["user_id"]
|
||||
responses:
|
||||
|
|
@ -134,7 +134,7 @@ paths:
|
|||
type: object
|
||||
403:
|
||||
description: |-
|
||||
You do not have permission to unban the user from the room. A meaningful ``errcode`` and description error text will be returned. Example reasons for rejections are:
|
||||
You do not have permission to unban the user from the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are:
|
||||
|
||||
- The unbanner's power level is insufficient to unban users from the room.
|
||||
examples:
|
||||
|
|
@ -59,14 +59,14 @@ paths:
|
|||
format: byte
|
||||
responses:
|
||||
200:
|
||||
description: The `MXC URI`_ for the uploaded content.
|
||||
description: The [MXC URI](/client-server-api/#matrix-content-mxc-uris) for the uploaded content.
|
||||
schema:
|
||||
type: object
|
||||
required: ["content_uri"]
|
||||
properties:
|
||||
content_uri:
|
||||
type: string
|
||||
description: "The `MXC URI`_ to the uploaded content."
|
||||
description: "The [MXC URI](/client-server-api/#matrix-content-mxc-uris) to the uploaded content."
|
||||
examples:
|
||||
application/json: {
|
||||
"content_uri": "mxc://example.com/AQwafuaFswefuhsfAFAgsw"
|
||||
|
|
@ -112,14 +112,14 @@ paths:
|
|||
x-example: matrix.org
|
||||
required: true
|
||||
description: |
|
||||
The server name from the ``mxc://`` URI (the authoritory component)
|
||||
The server name from the `mxc://` URI (the authoritory component)
|
||||
- in: path
|
||||
type: string
|
||||
name: mediaId
|
||||
x-example: ascERGshawAWawugaAcauga
|
||||
required: true
|
||||
description: |
|
||||
The media ID from the ``mxc://`` URI (the path component)
|
||||
The media ID from the `mxc://` URI (the path component)
|
||||
- in: query
|
||||
type: boolean
|
||||
name: allow_remote
|
||||
|
|
@ -177,20 +177,20 @@ paths:
|
|||
x-example: matrix.org
|
||||
required: true
|
||||
description: |
|
||||
The server name from the ``mxc://`` URI (the authoritory component)
|
||||
The server name from the `mxc://` URI (the authoritory component)
|
||||
- in: path
|
||||
type: string
|
||||
name: mediaId
|
||||
x-example: ascERGshawAWawugaAcauga
|
||||
required: true
|
||||
description: |
|
||||
The media ID from the ``mxc://`` URI (the path component)
|
||||
The media ID from the `mxc://` URI (the path component)
|
||||
- in: path
|
||||
type: string
|
||||
name: fileName
|
||||
x-example: filename.jpg
|
||||
required: true
|
||||
description: A filename to give in the ``Content-Disposition`` header.
|
||||
description: A filename to give in the `Content-Disposition` header.
|
||||
- in: query
|
||||
type: boolean
|
||||
name: allow_remote
|
||||
|
|
@ -210,7 +210,7 @@ paths:
|
|||
type: "string"
|
||||
Content-Disposition:
|
||||
description: |-
|
||||
The ``fileName`` requested or the name of the file that was previously
|
||||
The `fileName` requested or the name of the file that was previously
|
||||
uploaded, if set.
|
||||
type: "string"
|
||||
schema:
|
||||
|
|
@ -238,7 +238,7 @@ paths:
|
|||
summary: Download a thumbnail of content from the content repository
|
||||
description: |-
|
||||
Download a thumbnail of content from the content repository.
|
||||
See the `thumbnailing <#thumbnails>`_ section for more information.
|
||||
See the [Thumbnails](/client-server-api/#thumbnails) section for more information.
|
||||
operationId: getContentThumbnail
|
||||
produces: ["image/jpeg", "image/png"]
|
||||
parameters:
|
||||
|
|
@ -248,14 +248,14 @@ paths:
|
|||
required: true
|
||||
x-example: example.org
|
||||
description: |
|
||||
The server name from the ``mxc://`` URI (the authoritory component)
|
||||
The server name from the `mxc://` URI (the authoritory component)
|
||||
- in: path
|
||||
type: string
|
||||
name: mediaId
|
||||
x-example: ascERGshawAWawugaAcauga
|
||||
required: true
|
||||
description: |
|
||||
The media ID from the ``mxc://`` URI (the path component)
|
||||
The media ID from the `mxc://` URI (the path component)
|
||||
- in: query
|
||||
type: integer
|
||||
x-example: 64
|
||||
|
|
@ -278,7 +278,7 @@ paths:
|
|||
name: method
|
||||
x-example: "scale"
|
||||
description: |-
|
||||
The desired resizing method. See the `thumbnailing <#thumbnails>`_
|
||||
The desired resizing method. See the [Thumbnails](/client-server-api/#thumbnails)
|
||||
section for more information.
|
||||
- in: query
|
||||
type: boolean
|
||||
|
|
@ -347,11 +347,11 @@ paths:
|
|||
Get information about a URL for the client. Typically this is called when a
|
||||
client sees a URL in a message and wants to render a preview for the user.
|
||||
|
||||
.. Note::
|
||||
Clients should consider avoiding this endpoint for URLs posted in encrypted
|
||||
rooms. Encrypted rooms often contain more sensitive information the users
|
||||
do not want to share with the homeserver, and this can mean that the URLs
|
||||
being shared should also not be shared with the homeserver.
|
||||
**Note:**
|
||||
Clients should consider avoiding this endpoint for URLs posted in encrypted
|
||||
rooms. Encrypted rooms often contain more sensitive information the users
|
||||
do not want to share with the homeserver, and this can mean that the URLs
|
||||
being shared should also not be shared with the homeserver.
|
||||
|
||||
operationId: getUrlPreview
|
||||
produces: ["application/json"]
|
||||
|
|
@ -390,7 +390,7 @@ paths:
|
|||
"og:image":
|
||||
type: string
|
||||
description: |-
|
||||
An `MXC URI`_ to the image. Omitted if there is no image.
|
||||
An [MXC URI](/client-server-api/#matrix-content-mxc-uris) to the image. Omitted if there is no image.
|
||||
examples:
|
||||
application/json: {
|
||||
"og:title": "Matrix Blog Post",
|
||||
|
|
@ -38,41 +38,39 @@ paths:
|
|||
the new room, including checking power levels for each event. It MUST
|
||||
apply the events implied by the request in the following order:
|
||||
|
||||
1. The ``m.room.create`` event itself. Must be the first event in the
|
||||
1. The `m.room.create` event itself. Must be the first event in the
|
||||
room.
|
||||
|
||||
2. An ``m.room.member`` event for the creator to join the room. This is
|
||||
2. An `m.room.member` event for the creator to join the room. This is
|
||||
needed so the remaining events can be sent.
|
||||
|
||||
3. A default ``m.room.power_levels`` event, giving the room creator
|
||||
3. A default `m.room.power_levels` event, giving the room creator
|
||||
(and not other members) permission to send state events. Overridden
|
||||
by the ``power_level_content_override`` parameter.
|
||||
by the `power_level_content_override` parameter.
|
||||
|
||||
4. Events set by the ``preset``. Currently these are the ``m.room.join_rules``,
|
||||
``m.room.history_visibility``, and ``m.room.guest_access`` state events.
|
||||
4. Events set by the `preset`. Currently these are the `m.room.join_rules`,
|
||||
`m.room.history_visibility`, and `m.room.guest_access` state events.
|
||||
|
||||
5. Events listed in ``initial_state``, in the order that they are
|
||||
5. Events listed in `initial_state`, in the order that they are
|
||||
listed.
|
||||
|
||||
6. Events implied by ``name`` and ``topic`` (``m.room.name`` and ``m.room.topic``
|
||||
6. Events implied by `name` and `topic` (`m.room.name` and `m.room.topic`
|
||||
state events).
|
||||
|
||||
7. Invite events implied by ``invite`` and ``invite_3pid`` (``m.room.member`` with
|
||||
``membership: invite`` and ``m.room.third_party_invite``).
|
||||
7. Invite events implied by `invite` and `invite_3pid` (`m.room.member` with
|
||||
`membership: invite` and `m.room.third_party_invite`).
|
||||
|
||||
The available presets do the following with respect to room state:
|
||||
|
||||
======================== ============== ====================== ================ =========
|
||||
Preset ``join_rules`` ``history_visibility`` ``guest_access`` Other
|
||||
======================== ============== ====================== ================ =========
|
||||
``private_chat`` ``invite`` ``shared`` ``can_join``
|
||||
``trusted_private_chat`` ``invite`` ``shared`` ``can_join`` All invitees are given the same power level as the room creator.
|
||||
``public_chat`` ``public`` ``shared`` ``forbidden``
|
||||
======================== ============== ====================== ================ =========
|
||||
| Preset | `join_rules` | `history_visibility` | `guest_access` | Other |
|
||||
|------------------------|--------------|----------------------|----------------|-------|
|
||||
| `private_chat` | `invite` | `shared` | `can_join` | |
|
||||
| `trusted_private_chat` | `invite` | `shared` | `can_join` | All invitees are given the same power level as the room creator. |
|
||||
| `public_chat` | `public` | `shared` | `forbidden` | |
|
||||
|
||||
The server will create a ``m.room.create`` event in the room with the
|
||||
The server will create a `m.room.create` event in the room with the
|
||||
requesting user as the creator, alongside other keys provided in the
|
||||
``creation_content``.
|
||||
`creation_content`.
|
||||
operationId: createRoom
|
||||
security:
|
||||
- accessToken: []
|
||||
|
|
@ -97,12 +95,12 @@ paths:
|
|||
type: string
|
||||
enum: ["public", "private"]
|
||||
description: |-
|
||||
A ``public`` visibility indicates that the room will be shown
|
||||
in the published room list. A ``private`` visibility will hide
|
||||
A `public` visibility indicates that the room will be shown
|
||||
in the published room list. A `private` visibility will hide
|
||||
the room from the published room list. Rooms default to
|
||||
``private`` visibility if this key is not included. NB: This
|
||||
should not be confused with ``join_rules`` which also uses the
|
||||
word ``public``.
|
||||
`private` visibility if this key is not included. NB: This
|
||||
should not be confused with `join_rules` which also uses the
|
||||
word `public`.
|
||||
room_alias_name:
|
||||
type: string
|
||||
description: |-
|
||||
|
|
@ -111,22 +109,22 @@ paths:
|
|||
room. The alias will belong on the *same* homeserver which
|
||||
created the room. For example, if this was set to "foo" and
|
||||
sent to the homeserver "example.com" the complete room alias
|
||||
would be ``#foo:example.com``.
|
||||
would be `#foo:example.com`.
|
||||
|
||||
The complete room alias will become the canonical alias for
|
||||
the room.
|
||||
name:
|
||||
type: string
|
||||
description: |-
|
||||
If this is included, an ``m.room.name`` event will be sent
|
||||
If this is included, an `m.room.name` event will be sent
|
||||
into the room to indicate the name of the room. See Room
|
||||
Events for more information on ``m.room.name``.
|
||||
Events for more information on `m.room.name`.
|
||||
topic:
|
||||
type: string
|
||||
description: |-
|
||||
If this is included, an ``m.room.topic`` event will be sent
|
||||
If this is included, an `m.room.topic` event will be sent
|
||||
into the room to indicate the topic for the room. See Room
|
||||
Events for more information on ``m.room.topic``.
|
||||
Events for more information on `m.room.topic`.
|
||||
invite:
|
||||
type: array
|
||||
description: |-
|
||||
|
|
@ -155,7 +153,7 @@ paths:
|
|||
medium:
|
||||
type: string
|
||||
# TODO: Link to Identity Service spec when it eixsts
|
||||
description: The kind of address being passed in the address field, for example ``email``.
|
||||
description: The kind of address being passed in the address field, for example `email`.
|
||||
address:
|
||||
type: string
|
||||
description: The invitee's third party identifier.
|
||||
|
|
@ -165,16 +163,16 @@ paths:
|
|||
description: |-
|
||||
The room version to set for the room. If not provided, the homeserver is
|
||||
to use its configured default. If provided, the homeserver will return a
|
||||
400 error with the errcode ``M_UNSUPPORTED_ROOM_VERSION`` if it does not
|
||||
400 error with the errcode `M_UNSUPPORTED_ROOM_VERSION` if it does not
|
||||
support the room version.
|
||||
example: "1"
|
||||
creation_content:
|
||||
title: CreationContent
|
||||
type: object
|
||||
description: |-
|
||||
Extra keys, such as ``m.federate``, to be added to the content
|
||||
of the `m.room.create`_ event. The server will clobber the following
|
||||
keys: ``creator``, ``room_version``. Future versions of the specification
|
||||
Extra keys, such as `m.federate`, to be added to the content
|
||||
of the [`m.room.create`](client-server-api/#mroomcreate) event. The server will clobber the following
|
||||
keys: `creator`, `room_version`. Future versions of the specification
|
||||
may allow the server to clobber other keys.
|
||||
initial_state:
|
||||
type: array
|
||||
|
|
@ -184,8 +182,8 @@ paths:
|
|||
room. The expected format of the state events are an object
|
||||
with type, state_key and content keys set.
|
||||
|
||||
Takes precedence over events set by ``preset``, but gets
|
||||
overriden by ``name`` and ``topic`` keys.
|
||||
Takes precedence over events set by `preset`, but gets
|
||||
overriden by `name` and `topic` keys.
|
||||
items:
|
||||
type: object
|
||||
title: StateEvent
|
||||
|
|
@ -207,22 +205,23 @@ paths:
|
|||
Convenience parameter for setting various default state events
|
||||
based on a preset.
|
||||
|
||||
If unspecified, the server should use the ``visibility`` to determine
|
||||
which preset to use. A visbility of ``public`` equates to a preset of
|
||||
``public_chat`` and ``private`` visibility equates to a preset of
|
||||
``private_chat``.
|
||||
If unspecified, the server should use the `visibility` to determine
|
||||
which preset to use. A visbility of `public` equates to a preset of
|
||||
`public_chat` and `private` visibility equates to a preset of
|
||||
`private_chat`.
|
||||
is_direct:
|
||||
type: boolean
|
||||
description: |-
|
||||
This flag makes the server set the ``is_direct`` flag on the
|
||||
``m.room.member`` events sent to the users in ``invite`` and
|
||||
``invite_3pid``. See `Direct Messaging`_ for more information.
|
||||
This flag makes the server set the `is_direct` flag on the
|
||||
`m.room.member` events sent to the users in `invite` and
|
||||
`invite_3pid`. See [Direct Messaging](/client-server-api/#direct-messaging) for more information.
|
||||
power_level_content_override:
|
||||
title: Power Level Event Content
|
||||
type: object
|
||||
description: |-
|
||||
The power level content to override in the default power level
|
||||
event. This object is applied on top of the generated `m.room.power_levels`_
|
||||
event. This object is applied on top of the generated
|
||||
[`m.room.power_levels`](client-server-api/#mroompower_levels)
|
||||
event content prior to it being sent to the room. Defaults to
|
||||
overriding nothing.
|
||||
responses:
|
||||
|
|
@ -244,24 +243,24 @@ paths:
|
|||
400:
|
||||
description: |-
|
||||
|
||||
The request is invalid. A meaningful ``errcode`` and description
|
||||
The request is invalid. A meaningful `errcode` and description
|
||||
error text will be returned. Example reasons for rejection include:
|
||||
|
||||
- The request body is malformed (``errcode`` set to ``M_BAD_JSON``
|
||||
or ``M_NOT_JSON``).
|
||||
- The request body is malformed (`errcode` set to `M_BAD_JSON`
|
||||
or `M_NOT_JSON`).
|
||||
|
||||
- The room alias specified is already taken (``errcode`` set to
|
||||
``M_ROOM_IN_USE``).
|
||||
- The room alias specified is already taken (`errcode` set to
|
||||
`M_ROOM_IN_USE`).
|
||||
|
||||
- The initial state implied by the parameters to the request is
|
||||
invalid: for example, the user's ``power_level`` is set below
|
||||
that necessary to set the room name (``errcode`` set to
|
||||
``M_INVALID_ROOM_STATE``).
|
||||
invalid: for example, the user's `power_level` is set below
|
||||
that necessary to set the room name (`errcode` set to
|
||||
`M_INVALID_ROOM_STATE`).
|
||||
|
||||
- The homeserver doesn't support the requested room version, or
|
||||
one or more users being invited to the new room are residents
|
||||
of a homeserver which does not support the requested room version.
|
||||
The ``errcode`` will be ``M_UNSUPPORTED_ROOM_VERSION`` in these
|
||||
The `errcode` will be `M_UNSUPPORTED_ROOM_VERSION` in these
|
||||
cases.
|
||||
schema:
|
||||
"$ref": "definitions/errors/error.yaml"
|
||||
|
|
@ -33,7 +33,7 @@ paths:
|
|||
description: |-
|
||||
Publishes cross-signing keys for the user.
|
||||
|
||||
This API endpoint uses the `User-Interactive Authentication API`_.
|
||||
This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
|
||||
operationId: uploadCrossSigningKeys
|
||||
security:
|
||||
- accessToken: []
|
||||
|
|
@ -110,9 +110,9 @@ paths:
|
|||
The input was invalid in some way. This can include one of the
|
||||
following error codes:
|
||||
|
||||
* ``M_INVALID_SIGNATURE``: For example, the self-signing or
|
||||
* `M_INVALID_SIGNATURE`: For example, the self-signing or
|
||||
user-signing key had an incorrect signature.
|
||||
* ``M_MISSING_PARAM``: No master key is available.
|
||||
* `M_MISSING_PARAM`: No master key is available.
|
||||
schema:
|
||||
type: object
|
||||
example: {
|
||||
|
|
@ -207,8 +207,8 @@ paths:
|
|||
type: object
|
||||
description: |-
|
||||
A map from user ID to key ID to an error for any signatures
|
||||
that failed. If a signature was invalid, the ``errcode`` will
|
||||
be set to ``M_INVALID_SIGNATURE``.
|
||||
that failed. If a signature was invalid, the `errcode` will
|
||||
be set to `M_INVALID_SIGNATURE`.
|
||||
additionalProperties:
|
||||
type: object
|
||||
additionalProperties:
|
||||
|
|
@ -33,7 +33,7 @@ properties:
|
|||
type: string
|
||||
description: |-
|
||||
The public key. The object must have exactly one property, whose name is
|
||||
in the form ``<algorithm>:<unpadded_base64_public_key>``, and whose value
|
||||
in the form `<algorithm>:<unpadded_base64_public_key>`, and whose value
|
||||
is the unpadded base64 public key.
|
||||
example:
|
||||
"ed25519:alice+base64+public+key": "alice+base64+public+key"
|
||||
|
|
@ -41,8 +41,8 @@ properties:
|
|||
type: object
|
||||
title: Signatures
|
||||
description: |-
|
||||
Signatures of the key, calculated using the process described at `Signing
|
||||
JSON`_. Optional for the master key. Other keys must be signed by the
|
||||
Signatures of the key, calculated using the process described at [Signing JSON](/appendices/#signing-json).
|
||||
Optional for the master key. Other keys must be signed by the
|
||||
user\'s master key.
|
||||
example: {
|
||||
"@alice:example.com": {
|
||||
|
|
@ -38,7 +38,7 @@ properties:
|
|||
type: object
|
||||
description: |-
|
||||
Public identity keys. The names of the properties should be in the
|
||||
format ``<algorithm>:<device_id>``. The keys themselves should be
|
||||
format `<algorithm>:<device_id>`. The keys themselves should be
|
||||
encoded as specified by the key algorithm.
|
||||
additionalProperties:
|
||||
type: string
|
||||
|
|
@ -50,10 +50,9 @@ properties:
|
|||
title: Signatures
|
||||
description: |-
|
||||
Signatures for the device key object. A map from user ID, to a map from
|
||||
``<algorithm>:<device_id>`` to the signature.
|
||||
`<algorithm>:<device_id>` to the signature.
|
||||
|
||||
The signature is calculated using the process described at `Signing
|
||||
JSON`_.
|
||||
The signature is calculated using the process described at [Signing JSON](/appendices/#signing-json).
|
||||
additionalProperties:
|
||||
type: object
|
||||
additionalProperties:
|
||||
|
|
@ -44,8 +44,8 @@ properties:
|
|||
format: int64
|
||||
type: integer
|
||||
prev_content:
|
||||
description: Optional. The previous ``content`` for this state. This will
|
||||
be present only for state events appearing in the ``timeline``. If this
|
||||
description: Optional. The previous `content` for this state. This will
|
||||
be present only for state events appearing in the `timeline`. If this
|
||||
is not a state event, or there is no previous content, this key will be
|
||||
missing.
|
||||
title: EventContent
|
||||
|
|
@ -17,7 +17,7 @@ properties:
|
|||
description: List of events.
|
||||
items:
|
||||
allOf:
|
||||
- $ref: event-schemas/schema/core-event-schema/event.yaml
|
||||
- $ref: ../../../event-schemas/schema/core-event-schema/event.yaml
|
||||
type: object
|
||||
type: array
|
||||
type: object
|
||||
|
|
@ -19,14 +19,14 @@ properties:
|
|||
not_senders:
|
||||
description: A list of sender IDs to exclude. If this list is absent then no senders
|
||||
are excluded. A matching sender will be excluded even if it is listed in the
|
||||
``'senders'`` filter.
|
||||
`'senders'` filter.
|
||||
items:
|
||||
type: string
|
||||
type: array
|
||||
not_types:
|
||||
description: A list of event types to exclude. If this list is absent then no
|
||||
event types are excluded. A matching type will be excluded even if it is listed
|
||||
in the ``'types'`` filter. A '*' can be used as a wildcard to match any sequence
|
||||
in the `'types'` filter. A '*' can be used as a wildcard to match any sequence
|
||||
of characters.
|
||||
items:
|
||||
type: string
|
||||
|
|
@ -39,7 +39,7 @@ properties:
|
|||
type: array
|
||||
types:
|
||||
description: A list of event types to include. If this list is absent then all
|
||||
event types are included. A ``'*'`` can be used as a wildcard to match any sequence
|
||||
event types are included. A `'*'` can be used as a wildcard to match any sequence
|
||||
of characters.
|
||||
items:
|
||||
type: string
|
||||
|
|
@ -35,7 +35,7 @@ properties:
|
|||
session_data:
|
||||
description: |-
|
||||
Algorithm-dependent data. See the documentation for the backup
|
||||
algorithms in `Server-side key backups`_ for more information on the
|
||||
algorithms in [Server-side key backups](/client-server-api/#server-side-key-backups) for more information on the
|
||||
expected format of the data.
|
||||
type: object
|
||||
example: {
|
||||
|
|
@ -19,10 +19,10 @@ properties:
|
|||
description: |-
|
||||
An access token the consumer may use to verify the identity of
|
||||
the person who generated the token. This is given to the federation
|
||||
API ``GET /openid/userinfo`` to verify the user's identity.
|
||||
API `GET /openid/userinfo` to verify the user's identity.
|
||||
token_type:
|
||||
type: string
|
||||
description: The string ``Bearer``.
|
||||
description: The string `Bearer`.
|
||||
matrix_server_name:
|
||||
type: string
|
||||
description: |-
|
||||
|
|
@ -18,30 +18,30 @@ properties:
|
|||
kind:
|
||||
type: string
|
||||
description: |-
|
||||
The kind of condition to apply. See `conditions <#conditions>`_ for
|
||||
The kind of condition to apply. See [conditions](/client-server-api/#conditions) for
|
||||
more information on the allowed kinds and how they work.
|
||||
key:
|
||||
type: string
|
||||
description: |-
|
||||
Required for ``event_match`` conditions. The dot-separated field of the
|
||||
Required for `event_match` conditions. The dot-separated field of the
|
||||
event to match.
|
||||
|
||||
Required for ``sender_notification_permission`` conditions. The field in
|
||||
Required for `sender_notification_permission` conditions. The field in
|
||||
the power level event the user needs a minimum power level for. Fields
|
||||
must be specified under the ``notifications`` property in the power level
|
||||
event's ``content``.
|
||||
must be specified under the `notifications` property in the power level
|
||||
event's `content`.
|
||||
x-example: content.body
|
||||
pattern:
|
||||
type: string
|
||||
description: |-
|
||||
Required for ``event_match`` conditions. The glob-style pattern to
|
||||
Required for `event_match` conditions. The glob-style pattern to
|
||||
match against. Patterns with no special glob characters should be
|
||||
treated as having asterisks prepended and appended when testing the
|
||||
condition.
|
||||
is:
|
||||
type: string
|
||||
description: |-
|
||||
Required for ``room_member_count`` conditions. A decimal integer
|
||||
Required for `room_member_count` conditions. A decimal integer
|
||||
optionally prefixed by one of, ==, <, >, >= or <=. A prefix of < matches
|
||||
rooms where the member count is strictly less than the given number and
|
||||
so forth. If no prefix is present, this parameter defaults to ==.
|
||||
|
|
@ -43,11 +43,11 @@ properties:
|
|||
description: |-
|
||||
The conditions that must hold true for an event in order for a rule to be
|
||||
applied to an event. A rule with no conditions always matches. Only
|
||||
applicable to ``underride`` and ``override`` rules.
|
||||
applicable to `underride` and `override` rules.
|
||||
pattern:
|
||||
type: string
|
||||
description: |-
|
||||
The glob-style pattern to match against. Only applicable to ``content``
|
||||
The glob-style pattern to match against. Only applicable to `content`
|
||||
rules.
|
||||
required:
|
||||
- actions
|
||||
|
|
@ -24,7 +24,7 @@ allOf:
|
|||
3PID verification.
|
||||
|
||||
This parameter is deprecated with a plan to be removed in a future specification
|
||||
version for ``/account/password`` and ``/register`` requests.
|
||||
version for `/account/password` and `/register` requests.
|
||||
example: "id.example.com"
|
||||
id_access_token:
|
||||
type: string
|
||||
|
|
@ -33,4 +33,4 @@ allOf:
|
|||
can treat this as optional to distinguish between r0.5-compatible clients
|
||||
and this specification version.
|
||||
|
||||
Required if an ``id_server`` is supplied.
|
||||
Required if an `id_server` is supplied.
|
||||
|
|
@ -24,7 +24,7 @@ allOf:
|
|||
3PID verification.
|
||||
|
||||
This parameter is deprecated with a plan to be removed in a future specification
|
||||
version for ``/account/password`` and ``/register`` requests.
|
||||
version for `/account/password` and `/register` requests.
|
||||
example: "id.example.com"
|
||||
id_access_token:
|
||||
type: string
|
||||
|
|
@ -33,4 +33,4 @@ allOf:
|
|||
can treat this as optional to distinguish between r0.5-compatible clients
|
||||
and this specification version.
|
||||
|
||||
Required if an ``id_server`` is supplied.
|
||||
Required if an `id_server` is supplied.
|
||||
|
|
@ -17,7 +17,7 @@ properties:
|
|||
type: string
|
||||
description: |-
|
||||
The session ID. Session IDs are opaque strings that must consist entirely
|
||||
of the characters ``[0-9a-zA-Z.=_-]``. Their length must not exceed 255
|
||||
of the characters `[0-9a-zA-Z.=_-]`. Their length must not exceed 255
|
||||
characters and they must not be empty.
|
||||
example: "123abc"
|
||||
submit_url:
|
||||
|
|
@ -25,13 +25,13 @@ properties:
|
|||
description: |-
|
||||
An optional field containing a URL where the client must submit the
|
||||
validation token to, with identical parameters to the Identity Service
|
||||
API's ``POST /validate/email/submitToken`` endpoint (without the requirement
|
||||
API's `POST /validate/email/submitToken` endpoint (without the requirement
|
||||
for an access token). The homeserver must send this token to the user (if
|
||||
applicable), who should then be prompted to provide it to the client.
|
||||
|
||||
If this field is not present, the client can assume that verification
|
||||
will happen without the client's involvement provided the homeserver
|
||||
advertises this specification version in the ``/versions`` response
|
||||
advertises this specification version in the `/versions` response
|
||||
(ie: r0.5.0).
|
||||
example: "https://example.org/path/to/submitToken"
|
||||
required: ['sid']
|
||||
|
|
@ -16,7 +16,7 @@ properties:
|
|||
description: List of events.
|
||||
items:
|
||||
allOf:
|
||||
- $ref: event-schemas/schema/core-event-schema/sync_room_event.yaml
|
||||
- $ref: ../../../event-schemas/schema/core-event-schema/sync_room_event.yaml
|
||||
type: object
|
||||
required:
|
||||
- event_id
|
||||
|
|
@ -19,20 +19,20 @@ allOf:
|
|||
lazy_load_members:
|
||||
type: boolean
|
||||
description: |-
|
||||
If ``true``, enables lazy-loading of membership events. See
|
||||
`Lazy-loading room members <#lazy-loading-room-members>`_
|
||||
for more information. Defaults to ``false``.
|
||||
If `true`, enables lazy-loading of membership events. See
|
||||
[Lazy-loading room members](/client-server-api/#lazy-loading-room-members)
|
||||
for more information. Defaults to `false`.
|
||||
include_redundant_members:
|
||||
type: boolean
|
||||
description: |-
|
||||
If ``true``, sends all membership events for all events, even if they have already
|
||||
If `true`, sends all membership events for all events, even if they have already
|
||||
been sent to the client. Does not
|
||||
apply unless ``lazy_load_members`` is ``true``. See
|
||||
`Lazy-loading room members <#lazy-loading-room-members>`_
|
||||
for more information. Defaults to ``false``.
|
||||
apply unless `lazy_load_members` is `true`. See
|
||||
[Lazy-loading room members](/client-server-api/#lazy-loading-room-members)
|
||||
for more information. Defaults to `false`.
|
||||
not_rooms:
|
||||
description: A list of room IDs to exclude. If this list is absent then no rooms
|
||||
are excluded. A matching room will be excluded even if it is listed in the ``'rooms'``
|
||||
are excluded. A matching room will be excluded even if it is listed in the `'rooms'`
|
||||
filter.
|
||||
items:
|
||||
type: string
|
||||
|
|
@ -45,5 +45,5 @@ allOf:
|
|||
type: array
|
||||
contains_url:
|
||||
type: boolean
|
||||
description: If ``true``, includes only events with a ``url`` key in their content. If
|
||||
``false``, excludes those events. If omitted, ``url`` key is not considered for filtering.
|
||||
description: If `true`, includes only events with a `url` key in their content. If
|
||||
`false`, excludes those events. If omitted, `url` key is not considered for filtering.
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue